On Jun 21, 2007, at 11:48 AM, Simon Marlow wrote:
Peter Tanski wrote:
If I could change one feature of the current system ... for known
systems use autoconf only to determine what the $(build) system is
and to ensure those programs are available, then jump into make
which would call pre-set configuration makefiles for that system.
So you'd hard-wire a bunch of things based on the platform name?
That sounds like entirely the wrong approach to me. It makes the
build system too brittle to changes in its environment: exactly the
problem that autoconf was designed to solve.
Maybe this depends on the type of convenience you want to offer GHC-
developers. With the autoconf system they are required (for Windows)
to download and install: Mingw, perl, python (for the testsuite),
flex, happy, alex and some others I can't remember right now. Oh
yeah, GMP. When I did that, autoconf gave me the convenience of
having those programs somewhere in my $PATH and if autoconf found
them I was good to go. The way I would change things would not be so
different, except that the developer would have to set up the build
environment: run from under Mingw, etc. The benefit would be that
instead of testing all the extra things autoconf tests for--path
separator, shell variables, big/little endian, the type of ld and the
commands to execute compile--those would be hard-wired because the
system is known. When things break down you don't have to search
through the long lines of output because you know what the initial
settings are and can even rely on them to help debug Make. This is
the way it is done for several systems: NextStep (now Apple) project
makefiles, Jam, and many of the recent build systems, including
CMake, Scons and WAF.
Just last week I got an email from someone who had downloaded Cygwin
and installed GMP but ran into problems compiling GHC because
autoconf couldn't find the installed-GMP and tried to build the old
GMP located in the rts directory instead--note: it fails under Cygwin
for GMP_CHECK_ASM_W32, an autoconf macro. Clear directions on where
to put things would have solved this, or a build system that had
better search capabilities--but I see your point about changing
things too much (there is a very delicate balance to things as they
are).
It does use a custom "configure" script written in Python (more
consistently portable, no temporary files of any kind in $
(srcdir)) ...
Adding a dependency on Python is already something I want to
avoid. One way we try to keep the GHC build system sane is by
keeping the external dependencies to a minimum (yes I know the
testsuite requires Python, but the build itself doesn't).
I fought with myself about this for awhile--the end result will
integrate into the main GHC configure.ac (as it should) but it will
have to be much simpler. I initially had a much more complex
autoconf-based system but that created temporary files in $(srcdir)
and it would not port well to other autoconf systems--even including
extra .m4 code for the tests (I ran into trouble running autoreconf
and even using a simple shell script that would run aclocal -Im4,
autoheader, automake -a, and autoconf separately, when porting from
autoconf 2.59 (OS X) to autoconf 2.61 (Ubuntu Linux) and autoconf
2.52 (Mingw)--the point being that a developer would be able to run
autoreconf and get the same thing back again). The python script
works well on all systems I have tested it on and I wanted to use
python to help run the C-based testing framework and handle auto-
tuning. I can put all that into a shell script but for Windows it
should be a DOS batch file, at least.
Windows developers should not be forced to run everything under Mingw
or Cygwin. There are two problems with $(srcdir): someone who wishes
to work out of a darcs repository will have to do a full copy of the
source directory if they don't have the ability to create a shadow
copy; and, those environments are themselves quite brittle--depending
on how you invoke Mingw, you may have a completely different $PATH
setup and for a Windows-native build you would have to manually add
the Windows tools to your path (calling vsvars32.bat, the file that
sets up the path for the MS Tools, from under Mingw doesn't work--
maybe I've forgotten something).
However, I admit I don't fully understand the problem you're trying
to solve, not having tried to do this myself. The GHC build system
now uses Cabal to build libraries (actually Cabal + make + a bit of
autoconf for some libraries). Why can't this method work for
building libraries on Windows native? We must port Cabal to
Windows native anyway, and then you have a library build system.
It seems everyone has been looking for a replacement to autoconf for
Cabal for quite some time now. John suggested using a complete
scripting language to do it and I had toyed with that prospect a
bit. A basic requirement would be that it is already available on
the majority of architectures where GHC has not been ported. A more
practical requirement would be that it has a definite syntax for all
architectures--no special shell quirks. Things that fit this bill
are JVM-based applications and Python--JVM being more portable. I
have to confess, I hate Java and I consider the language itself
plebian, or at least parochial. Two systems that would do better
with this are Jaskell (http://jaskell.codehaus.org/) or SISC (the
Scheme-to-Java compiler, at http://sisc-scheme.org/). In any case, a
good project would be a decent replacement for autoconf based on one
of these. Perhaps port Cabal to Jaskell?
I may have digressed there a little. Sorry. In any case, for
Windows-GHC it seems impractical to require developers to have Mingw
installed--the ported compiler will run through native-asm only so
they won't need to have perl installed; only GHC and Yasm and VS
(which is a long download but requires far learning for a Windows
developer). I can fairly easily change the library requirements for
Windows because I am only porting to variations of the Windows platform.
What I hope you would agree on for Windows-GHC is a build that ran
parallel to the autoconf-make system.
What I hope is that we don't have to do this :-)
It's a really big job but it seems more complete in the end. I think
we talked about this before: the cross-compile to get the hc-files
must use the Windows headers, then the hc-build script must be
modified to use the windows toolset. Both of these are quite
invasive and messy to the current system--imagine the makefile code
for DLL-building x10. Once that is done the Windows-GHC will have to
operate as an independent fork: I doubt many people will wish to do
another hc-build of it though it would be a good idea to keep the
files around. What I propose is to start using a different build
system starting with the hc-build script. Whatever the end result
is, GHC must be able to operate without Mingw and the GNU toolset.
If we were to use something other than GNU make, we should do it
wholesale, or not at all, IMO.
Yeah. Otherwise one system sits around and gets a few too many bugs
for anyone to want to fix it up again, then it rots away, leaving a
great many maggot-files of forgotten purpose scattered through your
source code. I spent quite some time searching, learning about and
using different build systems. John is right: aside from tracking
dependancies, it would also be better to maintain the configuration
and build system in a single language, as well. The problem of build
systems seems to be reaching a head outside these walls--I am
beginning to see stuff on this all over the place. I suggested a
special build for Windows because Windows is a "special" system--
practically everything else (I haven't heard anyone talk of porting
GHC to OS/2) is posix-based. There is only one special system to
maintain independently of posix and using, say, VS tools you will
have a ready supply of experienced programmers who would be grateful
for the opportunity to work with something familiar.
Cheers,
Pete
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
