[Yhc] Proposed replacement for Yhc's build system using CMake

[Thomas Shackell]

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