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