hi! i was playing now for several days with the prototype of the jam buildsystem and i would like to share my findings up to now.
the main thing i've learned, is to have a look at the build output instead of being focused on buildtimes only. more on this later... all numbers in this text are from my dedicated PIII 1800, a local OOo build environment with bash (m181) and complete dependencies, doing a complete build of sc, unless state otherwise. note: complete dependencies seem to be somehow broken at the moment but some simple checks seem to indicate that they are broken in a way that doesn't affect build times. first vanilla build gave me the following numbers (don't care too much about the seconds...): 158m01s - regular dmake build 55m22s - plugged in jam 29m21s - pure jam "plugged in jam" means build all targets jam is currently able to and start a regular build for the remaining. of the targets required in the module sc, currently the jam buildsystem isn't able to create .lib, .dll and .res files. although not building all targets, the numbers for a pure jam build were quite impressive. next thing i did was fetching some already existing optimizations from the CWS vq35 (guw.exe, "-spawn" dmake) and ause060 (batched makedepend). this brought down the dmake build times to 81m08s - dmake, -spawn, guw.exe, fast deps ok, not enough yet. since the jam build system already implemented two optimizations that are build system independend, PCH (precompiled header) and batched compiling, i tried to hack PCH usage into dmake (just for measurement, clean implementation has to make sure that the used cimpiler options match). while doing so, i noticed that the current jam prototype doesn't care too much about compile switches and the PCH implementation is broken by concept :(. so the resulting output of the current jam build are good for measurement at best. using the broken PCH implementation (may be fixable for the majority of object files but add yet another bit of complexity, regardless if jam or dmake) for measurement, the times went down a bit more: 47m17s - dmake with hacked PCH taking into account that jam doesn't compile with optimization and restricting the dmake build to the targets a pure jam build is able to do, i got: 40m50s - almost compareable dmake build this build is still not using batched compiling which will give yet another speedup... regarding reduced complexity, my current impression is that the jam build system is somehow "over simplified" to a degree where the output is unusable without major rewrite. the whole gathering of compiler switches and defines boils down to an almost static compiler line. the PCH usage doesn't care if the precompiled files are compiled with the same options, thus producing inconsistently compiled object files. this of cause gives real simple Jamfiles and also a bit of speedup. i'm still fighting, not to compare apples with oranges but my current feeling is that using jam instead of build/dmake will give a speedup of 10-20 percent at best. tschau... ause --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
