Mathieu Boespflug wrote:
Hi all,
I've had this for a while on the back burners, so I'm releasing it now
lest I forget about it completely. I have a set of patches to replace
the existing SCons based build system for Yhc with a new build system
based on CMake. You can get them by pulling from
http://code.haskell.org/~mboes/yhc.cmake
The rationale for this is that SCons is very slow and never worked on
my platform, neither has it worked for other people too, I am told.
Successive attempts to fix the many problems on my platform just
caused more problems and the overhead associated with tinkering and
refactoring python files for simple build tasks led me to consider
reimplementing the build system using a different build framework.
Yes, we've had quite a lot of problems relating to scons.
The goals for the new build system are simplicity and portability. GNU
autotools, affectionately known by many as autohell, are not suitable
here because they do not work natively on Windows (cygwin or MSYS is
required). Neil emphasized the importance of not imposing on the user
the need for a working cygwin installation simply to compile Yhc.
Well, here Neil and I disagree. Whilst 'autotools' in its fullness is
'autohell' parts of it are okay: make works nicely so long as you write
your Makefiles well (see "Recusive make considered harmful"), and
autoconf is just about tolerable. The other advantage of autoconf & make
is their ubiquity: they are well supported because they are "the standard".
It's true that you need cygwin or MSYS on windows, but as Neil himself
points out most windows users want binaries not source code. You can, as
an alternative, cross compile to windows from unix using mingw. I've
used this on other projects and it works nicely. Being able to use MSVC
to compile Yhc is a very moot point in my opinion. This is because Yhc
makes use of several gcc extensions, and since these aren't available on
MSVC it runs quite a lot slower as a result.
That said there is a certain amount of benefit to keeping all parties
happy where possible ;-)
> This
narrows down the choice of build frameworks quite a bit, and it seems
to me like CMake is our best option here in that it is likely to
require the least effort in supporting both the Windows and the
various Unix like platforms. Other options were to remain with SCons
but signifantly rework the code, or to switch to waf. Both options
require a working python installation and I am far from convinced that
writing Python code is the way to specify builld dependencies. Other
build frameworks simply did not seem to provide much in the way of
cross-platform automatic configuration.
Yes I've become very unconvinced of the scons idea of "you need a full
powered language to write build systems". In practice you seem to end up
with something as complicated as a program for something as simple as a
build system.
What's more CMake seems to be gaining a lot of traction lately, with
several high profile projects switching to CMake, such as KDE4 (after
having seriously considered bksys/waf), OpenSceneGraph, Scribus and
others. It seems to be well maintained and build an active community
around it. The principle of CMake is that build rules are specified
using a custom language from which regular Unix Makefiles are
generated, or MS Visual Studio project files, or something else,
depending on the available options on your platform. The only
prerequesite is a C++ compiler for building CMake on your platform and
a working make.
One important problem with the Scons system is that only one person was
familiar with scons. This became problematic as nobody else knew how to
add anything to the build system: a new target, additional options etc.
So an important question is "will the other Yhc developers be able to
modify the CMake files?".
I propose here a number of patches.
The first set of patches is for adding the CMake build system.
Currently this system can build the Yhc compiler, the C runtime,
libffi and yhe the GUI environment. The building of Haskell sources is
offloaded to Cabal whenever possible, and libffi is currently built
and configured by calling out to its autoconf configure script and
automake generated Makefile. This should make it easier to update
libffi from upstream. Currently there is no support for building the
Yhc libraries (ie the src/packages directory), because ideally that
would be done through Cabal but Cabal does not support building with
Yhc, yet. An interim solution would be needed in the interim until
Cabal gains proper dependency discovery and Yhc support.
Indeed, some temporary system would be necessary - possibly a rather
hacky CMake file?
The second set of patches removes SCons scripts that are sprinkled
around the repository. I believe this set of patches could be applied
at a later date, to allow the SCons build system and the CMake build
system to cohabit for a while, pending the CMake system surpassing the
SCons system in every way and getting a good shaking out for any
lurking bugs. However, the SCons system will need to be modified to
work with the updated libffi (see separate message on this mailing
list).
Agreed cohabitation is the best strategy for the moment, until the CMake
build system becomes stable :-)
The third set of patches remove a number of unused Makefiles which
seem to be holdovers from a previous build system and were never used
by the Scons based build system. These patches can be applied now and
probably wouldn't break anything, if indeed the files removed are not
currently used.
None of these are used any more, they were part of the original
autoconf&make system.
So there goes. I would appreciate any feedback on this proposed system
and as much testing as possible on as many platforms as we can get our
hands on. I have tested the builds on FreeBSD 7 and on Ubuntu Linux
7.10 but I have not tested on other platforms. Most notably, it would
be great if someone could take care of making this work on Windows,
since I don't have any Windows box at hand to test this on. Porting to
Mac OS X might require some work too, I'm not sure.
Both windows and Mac OS X have traditionally been the tricky cases for
the build systems Linux has usually always worked, probably because most
Yhc development is done by linux users :-)
Beyond building the libraries, further work would include integrating
Caveat: cmake generates a Makefile in src/runtime/BCKernel,
overwriting the existing Makefile in that directory currently used by
nhc98. The nhc98 Makefile will probably need to be renamed or
something.
nhc98 doesn't use the src/runtime/BCKernel makefile since that code is
Yhc specific. The only part of the code shared with nhc98 is the
src/compiler code.
Thanks for your efforts :-)
Tom
_______________________________________________
Yhc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/yhc
