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

Mathieu Boespflug mboes at tweag.net
Tue Nov 6 08:38:46 EST 2007


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.

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. 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.

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.

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.

Patches names:
* Introducing CMake for Yhc.
* Introduce CMake build system for BCKernel runtime.
* Cabalize src/interactive so that it may be build with CMake.
* Create cmake/modules dir and put CMake helper files in there.
* Add support for building libffi from CMake and make it a dependency
for building
 BCKernel.
* Add ability to build BCKernel with no dynamic linking support and
add extra test
s to find dlopen on Linux systems.
* Fix the fetch target in toplevel CMakeLists.txt.

In addition to the libffi from gcc-4.2 patch.

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).

Patch names:
* Remove scons build system.
* Remove scons files in src/interactive/.
* Remove SCons files for building libraries.
* Remove scons files for building runtime.
* Remove scons files for build src/tester.

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.

Patch names:
  * Remove top level Makefile and configure scripts.
  * Remove seemingly unused Makefile in src/interactive.
  * Remove Makefiles in libraries, holdover from a prior build system.
  * Remove msvc files in BCKernel directory.
  * Remove src/runtime/Makefile.

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.

Beyond building the libraries, further work would include integrating
the ycr2js translator into the build system.

Here's a short synopsis of how to use the new system.

Install CMake (apt-get cmake or equivalent on your platform). After
pulling the set 1 patches into your local yhc repo or creating a new
repo, do the following at the root of the repo:

$ cmake .         # note the period after cmake.
$ make fetch   # fetches all the libs and tools in other darcs repos
yhc depends on
$ make yhc     # for the compiler
$ make yhi      # for the C runtime
$ make yhe     # for the GUI environment

Alternatively you can

$ cmake .
$ make

To do all the above. make fetch only creates those repos that are
missing, essentially running a "darcs get" as appropriate. A regular
"darcs pull" will grab new patches for the Yhc repo but to update all
the dependencies wrt to their main darcs repo you can

$ make update

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.

In addition to the docs on the cmake.org website, there are some
tutorials to get you started at

http://www.linuxjournal.com/article/6700

and a subscribers only Linux Magazine article that you can
nevertheless access through Google's cache by searching "cmake: make
reloaded".

All the best,

Mathieu


More information about the Yhc mailing list