I spoke with some guys in the #boost chat room about this and they said it was one of the problems that they overcame in bjam, the inability to control dependencies. I'm not sure what I did, but at some point, I started having massive linking errors (missing symbols) as if one of the libraries (glestlib and/or gamelib) wasn't being linked in and it was excruciatingly irritating
I finally found an alternate solution and I reverted the creation of the gamelib and just encapsulated the glestadv and testgae in an if/else statement. I wish I had saved the intermediate state where I had it all working, but I got frustrated and have it working now and will probably leave it that way until a better solution comes along.
I do want to change the build system if Matthias wont be able to assist with issues like this, but I don't want to work on it now because I need to stay focused on completing the networking re-write (it's most of the way there now!). So for now, if you want to build the unit test, you run the following:
BUILD_UNIT_TESTS=yes jam
If you have previously built the game target (glestadv) then it will only compile the test code and then link. What I still might do is try to make a build target that will only build the precompiled headers, then one could build that target and then, in a
separate process build everything else with as many parallel jobs as you like. Example:
jam pch && jam -j5
Right now, I'm using two precompiled headers, one for shared_lib project and one for the game. Currently, I have them including every header file in each of those as well as external dependencies. Thus, if you change any header, it will cause them to be rebuilt, while at the same time, should contain most of the code that will need to be compiled. So if they are working correctly, they should speed up compile times a good deal.
I should add the note that the
Application rule accepts various options, one being "
independent", this option causes the target not to be included in the default "
all" target. However, it still added the object files, go figure.
If you're going to be changing the build system it might be good to look at http://code.google.com/p/waf/ or http://www.scons.org/ or http://premake.sourceforge.net/about (CEGUI uses the last one)
Well, if we're going to change it, I want it to be to something that can do the job and is maintainable. A standard autotools/make build is highly maintainable. I'm not hard set on that, but I don't want to run into the types of problems that we have with this build system where it's hard to maintain. Granted, Matthias' system has some incredible capabilities that it turns out aren't being exploited! It has the ability to generate msvc project files, but I never knew that until after I already had one working on my system and I never tried to figure out how to work it.