Compile Windows x86 and x64 side-by-side

[NVX]

Hi Carsten,

I realised a little while ago that building on a x64 Windows machine will only build x64, and not have an easy way to force it to build x86 with just a compile flag to SCons, which brings me to the second point that x64 and x86 builds appear to go to the same directory.

When developing on Windows, it is often useful to have both x86 and x64 built at the same time so that one can test that a change doesn't inadvertently break the build for the other architecture.

Is it possible to modify Cafu to build x86 and x64 targets in separate output folders, and if possible either have a flag or environment variable set to trigger building one version or the other, or even both at the same time (providing the build tools are installed)? Considering that almost all Windows boxes with x64 build tools also have x86, and a large user base of windows is still x86, if one was building a x64 game, chances are a x86 release would be provided as well.

Can't wait for VS2010 support as well, means I can finally uninstall VS2008

[Carsten]

Dear NVX,
thanks for your message!

Before I start with the reply, let me briefly summarize the latest developments:
The port to x64 Windows via the VM went very well, you probably got my notes that I left from time to time in the IRC channel. I also tested all changes under 32-bit Windows and 32- and 64-bit Linux, and applied them to the SVN trunk.

Unfortunately, a(nother) bug in SCons prevented linking the 64-bit binaries so far.

At the same time, my other Windows Vista ready-made system that I purchased a few years ago had to have it's mainboard replaced recently, and now it's denying MS Windows activation. Well -- I took the opportunity to purchase a new Win7 64-bit license, and will install it early next week.
This means that from next week on, I'll have a 64-bit Win7 for development (locally ) available!

Also at the same time, I've started to improve the SCons build script, and will probably commit the changes later today.

With all that said, let's get to your message:

I realised a little while ago that building on a x64 Windows machine will only build x64, and not have an easy way to force it to build x86 with just a compile flag to SCons, which brings me to the second point that x64 and x86 builds appear to go to the same directory.

Ah! These points are very good ones!
Having the built system build for another architecture will be a trivial one-line edit once my recent changes are complete,
and many thanks for reminding me that the results should go into different directories! (I've just updated the new SConstruct file accordingly.)

When developing on Windows, it is often useful to have both x86 and x64 built at the same time so that one can test that a change doesn't inadvertently break the build for the other architecture.

Yes, though this problem extends to other platforms (Linux and in the future, Mac) as well...

Is it possible to modify Cafu to build x86 and x64 targets in separate output folders, and if possible either have a flag or environment variable set to trigger building one version or the other, or even both at the same time (providing the build tools are installed)? Considering that almost all Windows boxes with x64 build tools also have x86, and a large user base of windows is still x86, if one was building a x64 game, chances are a x86 release would be provided as well.

Yes, I hope that I can finish the new SConstruct file today and that it will fix the problem.

Can't wait for VS2010 support as well, means I can finally uninstall VS2008

This is the second big problem at the moment: SCons does not yet have support for it (see my bug report).

I too have VC10 installed experimentally, along with a patched version of SCons to make it work, but the next problem is that VC10 (or the SDK) seems to now use different definitions for std::streampos and size_t, so there is additional work involved as well...

In summary:
I'm working on it, and will keep you up-to-date!

[Carsten]

Ok... here is an update:
The above mentioned changes went quite well, but before committing them to the trunk, I want to test them more thoroughly first, and thus have submitted the patch as a ticket first.

Will test it on the systems mentioned in the ticket, but also on my (now obsolete) WinVista with VC9Express, the soon installed new Win7, and of course on your VM.

[NVX]

Cool cool, let me know when you're up and running and done with the VM and I'll shut 'er down. If you need more time with it (to test on say VC9 full rather than VC9Exp) that's fine too.

[NVX]

VC10 (or the SDK) seems to now use different definitions for std::streampos and size_t, so there is additional work involved as well...

Just encountered this, odd thing is it seems to only effect x86 builds, x64 built fine (other than the above issue with incorrect libpath)

Makes me wonder if it's defined as 64bit on both (and thus on x86 builds size_t truncates to 32bit). C++0x might be the cause as well, but I couldn't find any confirmation of C++0x changing the definition of streampos/streamoff in that manor. Ah good fun, at least nullptr works on VS2010 now though

[Carsten]

Makes me wonder if it's defined as 64bit on both (and thus on x86 builds size_t truncates to 32bit).

Yes, that's what I suspect, too. I've not yet finished digging through the header files to find the confirmation in the definitions, but the right solution is certainly to use the proper data types (instead of size_t). I'll look into it during the next days.

C++0x might be the cause as well, but I couldn't find any confirmation of C++0x changing the definition of streampos/streamoff in that manor.

Well, no, that would be a matter of the C or standard library, but not of the language standart.