64-bit windows version?
p.tanski at gmail.com
Mon Jun 25 12:48:40 EDT 2007
On Jun 25, 2007, at 12:06 PM, skaller wrote:
> On Mon, 2007-06-25 at 11:43 -0400, Peter Tanski wrote:
>> It would be much better to have a single build system. I would
>> gladly replace the whole thing ...
> I am thinking of starting a new project (possibly as sourceforge)
> to implement a new build system. I think Erick Tryzelaar might
> also be interested. The rule would be: it isn't just for GHC.
> So any interested people would have to thrash out what to
> implement it in, and the overall requirements and design ideas.
> My basic idea is that it should be generic and package based,
> that is, it does NOT include special purpose tools as might
> be required to build, say, Haskell programs: these are
> represented by 'plugin' components.
> A rough model of this: think Debian package manager, but
> for source code not binaries.
I have been considering the same thing for some time, partly because
the specification properties of most available build systems are
terrible: XML is not a language (it is better as a back-end for a gui-
based build system); current plug-in systems (similar to what WAF
uses) are object-oriented and require a deep knowledge of the build
system API; others are manual hacks. One big thing to avoid are
cache-files: CMake, SCons, WAF, autotools, all use cache-files and
all run into problems when the cache files aren't cleaned or include
errors. (WAF has the best cache-file system--they are designed to be
human-readable.) I will gladly lend support to this.
An idea I have been kicking around is a hybrid between the autoconf
strategy and the commercial-setup strategy: add support for a
specification of program requirements, i.e., <stdint.h>, gcc/cl/icl,
things like that in a simple spec-document with dead-simple syntax,
then let the build system handle the rest--it would know what to do
for each architecture. That seems similar to the Debian package
What language are you thinking about using? Scheme seems good but
the build-language itself might be different; gui-support should be
available which says to me (horrors!) Java AWT--a cross-platform gui-
supported build system (not an IDE) would rock the world because it
doesn't exist. There are tons of Python packages out there (A-A-P,
hasn't been updated since 2003; SCons, WAF, Bakefile (uses Python)).
I don't know if this is possible in Felix.
Other requirements might be:
(1) never alter anything in the source directories--everything is
managed through the build directory
(2) ability to easily build separate targets from the command line,
similar to 'make test_shifts'--externally scriptable.
One thing other systems seem to fail at is building off the enormous
trove of information in autoconf--it's right there, open source, and
they reinvent the wheel when it comes to making configuration tests
or finding platform information (config.guess is essentially a
database of platform-specific information but is somewhat dated with
regard to newer systems, including OS X). On that note, a different
approach to configuration tests might be clearer knowledge about the
compilers: all these systems build small C programs to test certain
compiler characteristics and test for a 0 exit value. Well, CMake
does actually 'read' the output files for some things, such as
More information about the Glasgow-haskell-users