64-bit windows version?
p.tanski at gmail.com
Fri Jun 22 10:42:56 EDT 2007
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
More information about the Glasgow-haskell-users