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

[Mathieu Boespflug]

Hi,

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

I agree. CMake isn't as ubiquitous and what users are used to. Also it
isn't IMHO much better of a language than shell scripts + m4. However
I think it does have some advantages here. It's quite a bit faster
than autoconf and automake. It also generates much smaller Makefiles
and we don't need to distribute a big configure script. More
importantly, it's quite a bit simpler than autotools and easier and
faster to learn than autotools. And even more importantly:

> That said there is a certain amount of benefit to keeping all parties
> happy where possible ;-)

Precisely!

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

Yep.

> 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 think CMake files are easier to learn to write and read than
autoconf scripts. And a lot easier than scons scripts, which entail
learning a full programming language and a weird build model.
CMake files are fairly clear, and currently the two CMakeLists.txt
files in the proposed patches weigh in at 164 lines total, whilst
providing most of the core functionality of the scons scripts (notably
cmake doesn't build libraries atm). In comparison,

$ wc -l build/{SConscript.*,*.py,tools/*.py}
    1068 total

$ find src/packages/ -name SConscript | xargs wc -l

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

Yes. I'll get going on that, seeing as though the prerequesite support
from Cabal seems still a way off.

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

Heh. Any Yhc developer with a Mac OS X machine lying around?

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

Ok. I've made a new patch removing that Makefile.

Regards,

Mathieu