Build release and debug configurations in one command
I want my build server to be able to run "jam" and have that build absolutely everything, in all configurations. Configurations aren't targets, and setting CONFIG part-way through a script seems like a really bad idea. All the 'X on X' syntax looks strange to me but I'm guessing I may be able to achieve what I want that way. Before I potentially waste time trying though, is this possible with Jam?
That's a good question and I hope it can be done. I know it's possible with bjam (boost-build). Can't you set your build server with 2 different builds? Something like this:
I could do that, but executing it all in one command is both cleaner and potentially more efficient since both builds can be done concurrently.
JamPlus's Jambase can not currently handle this. This is a limitation of the Jambase, though. There has been some discussion about this on the Perforce Jam mailing list (such as http://maillist.perforce.com/pipermail/jamming/2008-August/002983.html).
No-op build time is incredibly important. My un-benchmarked worry is the sheer number of targets Jam might have to pick through and what that does to the no-op build time. If I have 5 platforms and 5 configurations per platform, that is 24 times more dependency graph nodes that have to be picked through during the build. The dependency graph can be targeted more tightly than that, though, so at the very least, it is 24 times more information on the various targets that must be parsed into the dependency.
Still, I am very interested in seeing how this could work out.
I'm moving away of bjam because of the no-op build time is way too long on our project (about 25 libs, 25 unittests executables, 3-4 real executables). My experience with bjam is similar to http://gamesfromwithin.com/?p=44 ... which is actually impossible to work with in TDD style. It's a shame because we created lots of rules for it that cannot be ported to jam easily. In the end, as soon as we added more target (debug, release, final, profile), more platforms (win32, game consoles, etc), the no-op time was growing to 35 seconds for a no-op. I can understand that their priority is not speed, but to support every compilers on every platform. It's just not my priority.
I was wondering, how are you planning to support more platforms? Everything is in the Jambase file right now, which I guess could grow to enormous proportion, which would add to the starting time of jam? By platforms, I'm more talking about consoles, so the environment could still be Windows/Unix, only the compilers could be something else.
In bjam, we modified it a little bit so that we could just say :
or to get it to compiles for a $(console_name),
we then parsed the command line for the option platform. We then loaded the platform compilers options only. Something similar could also be done in jamplus I guess?
That's absolutely fair enough, I hadn't considered the effect of including platforms into the mix, and of having more than two configurations - my project is very simple in this respect at the moment! I'll stick to Marc's suggestion of running two commands for now.
I managed to build some simple projects for the Xbox 360 a while ago without a great deal of modification to the Jambase. I don't remember why now, but there was some reason I had to do this in the JamPlus Jambase rather than in a project-local Jambase, and allowing that kind of extensibility would be the hard part of improving compatibility with other platforms!
JamPlus 0.4 has the ability to drop new platforms and configurations into a directory. While it isn't possible to ship an Xbox 360 configuration without Microsoft's blessing, you would populate either JamPlus's bin/modules/c-compilers/ directory or your own c-compilers/ directory with files of the following names:
- c-visualc-autodetect-x360.jam - This file would discover the location of the Xbox 360 SDK, either through a registry setting, environment variable, or just a hardcoded path.
- c-visualc-x360.jam - This file would set up the compiler locations, set Xbox 360 #defines, and patch into application builds to provide proper translation of executables and deployment to the Xbox 360 itself.
- c-visualc-x360-debug.jam (and so on, per config) - This file would set C/C++ compiler, library, and linker flags for the given platform.
Note that no changes to Jambase.jam are needed.
With a jam --workspace --config=filename.config setting, the Xbox 360 platform can be made available in the list of VALID_PLATFORMS. Through the same .config file, the available configurations can be changed.
If everything goes as planned, JamPlus 0.5 will autodetect the available platforms and configurations.
That's brilliant! A good solution :) This should go a long way towards persuading the guys at work that Jam is a viable build system for us - they didn't like that I had to change the Jambase to get it working.
Forgive me if I'm being really dumb though, but does this solve the original problem I was having, of building debug and release in one command? Or is this more a response to Marc's suggestions?
This was more of a response to Marc. I got the two conversations mixed up.
In any case, building all configurations (and/or platforms) will take additional Jambase work that won't happen before 0.4 ships. As it stands right now, I have one or two Mac OS X bugs and the rest of the documentation to write. So, the current nightly builds are a pretty close representation of what will ship. If you wanted to experiment with the ability to add Xbox 360 support, you could contact me offline, and I could work through it with you; that is, you provide the details, and I'll tell you where to hook it up.
It's ok, I actually had it working, minus the deployment step, not long after JamPlus was started. This should all just make it a lot easier and more 'official' :) Thanks for the offer of help though!