[bakefile-devel] 64-bit build option?

[Warren Young]

We just got our first question to the MySQL++ mailing list about
building it for 64-bit Windows. I was kind of surprised to see that
there seems to be no way to change the bkl file to cause generation of
64-bit vcproj files.

GlobalSection(SolutionConfigurationPlatforms) = preSolution
- Release|Win32 = Release|Win32
- Debug|Win32 = Debug|Win32
+ Debug|x64 = Debug|x64
+ Release|x64 = Release|x64
EndGlobalSection
- {FF09D392-E501-5DAB-B5A9-B1B97E246D37}.Debug|Win32.ActiveCfg = Debug|Win32
- {FF09D392-E501-5DAB-B5A9-B1B97E246D37}.Debug|Win32.Build.0 = Debug|Win32
+ {FF09D392-E501-5DAB-B5A9-B1B97E246D37}.Release|x64.ActiveCfg = Release|x64
+ {FF09D392-E501-5DAB-B5A9-B1B97E246D37}.Release|x64.Build.0 = Release|x64
<Platforms>
<Platform
Name="Win32"
/>
+ <Platform
+ Name="x64"
+ />
</Platforms>

Personally, I'm only looking to do an either/or build, not both
platforms at once. So, I think you can just change "Win32" to "x64"
here, rather than add the second <Platform> tag.

I got a bunch of other diffs, but nothing that seemed relevant. It all
looked like stuff Visual Studio just added when rewriting the file.

[Vaclav Slavik]

Post by Warren Young
Personally, I'm only looking to do an either/or build, not both
platforms at once. So, I think you can just change "Win32" to "x64"
here, rather than add the second <Platform> tag.
I got a bunch of other diffs, but nothing that seemed relevant.

What about the WIN32 preprocessor symbol that VC++ normally defines (see
related Bakefile fix: http://www.bakefile.org/changeset/1284)? Is it
still defined, is it replaced with WIN64 or something else?

Thanks,
Vaclav

[Warren Young]

Post by Vaclav Slavik
What about the WIN32 preprocessor symbol that VC++ normally defines (see
related Bakefile fix: http://www.bakefile.org/changeset/1284)? Is it
still defined, is it replaced with WIN64 or something else?

Yes, WIN32 is still defined for a 64-bit build. I thought at first I
had screwed something up, so I checked it a couple of different ways.

On reflection, I think I see why. There's no way to create a 64-bit
executable directly from the VC++ 2008 project wizard. You have to
start with a 32-bit project, add a 64-bit build configuration, and then
remove the 32-bit configuration. I'm sure this is why the 32-bit
references are still around. I doubt it's really intended, and may go
away in VC++ 2010. Personally, I would expect to test only _WINDOWS or
WIN64 as predefined symbols if I knew I was supporting 64-bit platforms.

I think I was wrong to suggest making it an either/or option. I now
think Bakefile should emit project files with build configurations for
both CPU types, at least for the next few years while the low end
completes the transition to 64-bit. AMD64/EM64T has won the war, and
even desktop machines are coming in 64-bit versions now. Meanwhile,
there is still demand for 32-bit binaries. If it isn't happening
already, it will certainly be the case in the future that building for
both CPU types will be wanted until 32-bit finally dies off.

I don't see any reason to have special support for other platforms, by
the way. Autoconf based systems, at least, already have good ways to
manage this, independent of Bakefile. It's not clear to me what the
options are with MinGW, though.

[Vaclav Slavik]

Hi,

Post by Warren Young

Post by Vaclav Slavik
What about the WIN32 preprocessor symbol that VC++ normally defines (see
related Bakefile fix: http://www.bakefile.org/changeset/1284)? Is it
still defined, is it replaced with WIN64 or something else?

Yes, WIN32 is still defined for a 64-bit build.

Makes sense, it's analogous to _WIN32/_WIN64 defined by the compiler --
the former is defined for both, see
http://msdn.microsoft.com/en-us/library/b0084kay.aspx

Post by Warren Young
away in VC++ 2010. Personally, I would expect to test only _WINDOWS or
WIN64 as predefined symbols if I knew I was supporting 64-bit platforms.

Better yet, test _WIN64.

Post by Warren Young
I think I was wrong to suggest making it an either/or option.

I agree. There's already support for multiple platforms (Win32 and
PocketPC) through MSVS_PLATFORMS variable, extending it to handle x64
too shouldn't be too much work.

In fact, it seems trivial: with the attached patch, running Bakefile
with -DMSVS_PLATFORMS=win32,win64 should generate hybrid project file
for both 32bit and 64bit builds (msvs200{5,8}prj formats only).

Post by Warren Young
It's not clear to me what the options are with MinGW, though.

http://mingw-w64.sourceforge.net/

Regards,
Vaclav

[Warren Young]

Post by Vaclav Slavik
through MSVS_PLATFORMS variable, extending it to handle x64
too shouldn't be too much work.

Not quite there yet. All the modules in my library compile, but then I

Post by Vaclav Slavik
fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'

Removing the x64 configuration and re-adding it using Visual Studio
doesn't fix the problem.

If I go back to the previous way, building only 32-bit project files and
then forking the 32-bit configuration to add a 64-bit one, I get many

Post by Vaclav Slavik
- ImportLibrary="$(PlatformName)\$(ConfigurationName)\mysqlpp.lib"
+ ImportLibrary="$(SolutionDir)$(ConfigurationName)\mysqlpp.lib"

Although the diff output is copious, it's all just repeats of the same
basic pattern: "$(PlatformName)\" vs. "$(SolutionDir)"

When you add the 64-bit build configuration through the GUI, VC++ puts
32-bit debug build outputs in Debug, but 64-bit outputs in x64\Debug.
The Bakefile way seems more sensible, giving Win32\Debug and x64\Debug,
but maybe there's some limitation in Visual Studio that requires the
other arrangement.

Another difficulty I'm running into is that with a hybrid project file,
how are you supposed to reference different libraries based on the CPU
type? The CRT issues are taken care of by the IDE, but what about
third-party libraries?

Take MySQL++, for example. It depends on the MySQL C API libraries,
naturally. When you install the 32-bit version of MySQL on Vista 64, it
goes in c:\Program Files (x86)\MySQL... Note the " (x86)" This is good
because you will also need the 64-bit version of MySQL, which uses all
the same file names, but goes in c:\Program Files\MySQL..., so the two
sets of binaries don't conflict. The thing is, though, how do I tell
Bakefile about this?

Currently, I have this:

<set var="MYSQL_WIN_DIR">
C:\Program Files\MySQL\MySQL Server 5.1
</set>
...
<include>$(MYSQL_WIN_DIR)\include</include>
<lib-path>$(MYSQL_WIN_DIR)\lib\opt</lib-path>
...etc...

Is there a way to set this variable conditionally based on the CPU
target, two different ways for a given Bakefile target type? It needs
to be set two different ways for msvs200[58]prj, one way when generating
the Win32 parts of *.vcproj and *.sln, and a different way for the Win64
parts.

Post by Vaclav Slavik
running Bakefile
with -DMSVS_PLATFORMS=win32,win64 should generate hybrid project file
for both 32bit and 64bit builds (msvs200{5,8}prj formats only).

Adding this to Bakefiles.bkgen isn't a hardship, but I wonder if it
shouldn't be the default, at least during this time of transition.

[Vaclav Slavik]

Post by Warren Young
Not quite there yet. All the modules in my library compile, but then I

Post by Vaclav Slavik
fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'

I don't see how does this end up here ("X86" string is nowhere to be
found in related Bakefile code), I'll need some help with this...

Post by Warren Young
Although the diff output is copious, it's all just repeats of the same
basic pattern: "$(PlatformName)\" vs. "$(SolutionDir)"
When you add the 64-bit build configuration through the GUI, VC++ puts
32-bit debug build outputs in Debug, but 64-bit outputs in x64\Debug.
The Bakefile way seems more sensible, giving Win32\Debug and x64\Debug,
but maybe there's some limitation in Visual Studio that requires the
other arrangement.

I doubt that, I've been using some very weird paths with no problems.
Anyway, this would be harder to change (see _default_builddir
definition).

Post by Warren Young
Another difficulty I'm running into is that with a hybrid project file,
how are you supposed to reference different libraries based on the CPU
type?

Use the pre-defined MSVS_PLATFORM
(http://www.bakefile.org/doc/ch07.html#sec.msvs2005prj.vars) <option> as
you do for any other conditional variables depending on your own
<option>s:

<set var="MYSQL_WIN_DIR">
<if cond="MSVS_PLATFORM=='win32'">foo</if>
<if cond="MSVS_PLATFORM=='win64'">bar</if>
</set>

(this only works for msvs200{5,8}prj formats, you have to add checks for
them too).

Post by Warren Young
Adding this to Bakefiles.bkgen isn't a hardship, but I wonder if it
shouldn't be the default, at least during this time of transition.

I don't think so -- it's still not frequently needed (you're the first
one to notice) and it adds extra configurations.

Vaclav