On Jun 22, 2007, at 9:45 AM, Simon Marlow wrote:
skaller wrote:
On Fri, 2007-06-22 at 12:03 +0100, Simon Marlow wrote:
Ok, you clearly have looked at a lot more build systems than I have. So you think there's a shift from autoconf-style "figure out the configuration by running tests" to having a database of configuration settings for various platforms?
I shouldn't overstate the situation: the other "complete" build systems, CMake and SCons do have autoconf capabilities in the way of finding headers and programs and checking test-compiles, the basic sanity checks--CMake has many more autoconf-like checks than SCons. Where they differ from the automake system seems to be their setup, which like Make has hard-coded settings for compilers, linkers, etc. (Some standard cmake settings are wrong for certain targets.) I don't know if you have any interest in pursuing or evaluating CMake (certainly not now) but the "standard" setup is stored in a standard directory on each platform, say, /usr/share/cmake-2.4/Modules/ Platform/$(platform).cmake and may be overridden by your own cmake file in, say, $(srcdir)/cmake/UserOverride.cmake. The preset-target-configuration build model I was referring to is a scaled-down version of the commercial practice which allows you to have a single system and simultaneously compile for many different architecture-platform combinations--once you have tested each and know how everything works. For the initial exploration, it is a different (more anal) strategy: before invading, get all the intelligence you can and prepare thoroughly. The GNU-Autoconf strategy is to keep a few troops who have already invaded many other places, adjust their all-purpose equipment a little for the mission and let them have at it. My gripe is that their equipment isn't very good. Cheers, Pete