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