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
Compile Windows x86 and x64 side-by-side
Re: Compile Windows x86 and x64 side-by-side
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:
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.)
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!
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:
Ah! These points are very good ones!NVX wrote: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.
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.)
Yes, though this problem extends to other platforms (Linux and in the future, Mac) as well...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, I hope that I can finish the new SConstruct file today and that it will fix the problem.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.
This is the second big problem at the moment: SCons does not yet have support for it (see my bug report).Can't wait for VS2010 support as well, means I can finally uninstall VS2008
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!
Best regards,
Carsten
Carsten
Re: Compile Windows x86 and x64 side-by-side
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.
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.
Best regards,
Carsten
Carsten
Re: Compile Windows x86 and x64 side-by-side
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.
Re: Compile Windows x86 and x64 side-by-side
Just encountered this, odd thing is it seems to only effect x86 builds, x64 built fine (other than the above issue with incorrect libpath)Carsten wrote:VC10 (or the SDK) seems to now use different definitions for std::streampos and size_t, so there is additional work involved as well...
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
Re: Compile Windows x86 and x64 side-by-side
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.NVX wrote:Makes me wonder if it's defined as 64bit on both (and thus on x86 builds size_t truncates to 32bit).
Well, no, that would be a matter of the C or standard library, but not of the language standart.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.
Best regards,
Carsten
Carsten
Who is online
Users browsing this forum: No registered users and 8 guests