Re: [Chicken-hackers] CMake vs. Autoconf

[felix winkelmann]

On 12/11/06, Brandon J. Van Every <address@hidden> wrote:

>  - CMake is the future of Chicken.

Well, that sounds a bit heavy, but I certainly prefer CMake to autotools.

>  - CMake is the primary build system on Windows.  The MinGW, Cygwin, and
> MSVC compilers are well tested.

Correct (I don't know about the current state of testing, but Windows builds
are exclusively with CMake).

>  - CMake is now the only way you can build for the MSVC compiler.

Right.

>  - CMake had some Linux bugs a month ago.  They seem to have been addressed
> by CMake 2.4.5.  The Linux build should be working fine, but hasn't received
> as much use and testing as the Autoconf build.

Yup.

>  - CMake has been known to build on the Mac, but nobody's been reporting on
> this recently.

Works ok for me.

>  - CMake is the canonical method by which Chicken DISTRIBUTIONS are created.
>  If you want to modify the canonical distro, you have to work with CMake.

Currently not. I forgot what exactly was the problem, but will check this once
I find some time and get back to you (Brandon) to make it work again.

>  - Brandon will chase complicated CMake problems, if they're important.
> Felix isn't a CMake guru yet.

...and probably never going to be.

>  - Autoconf is still supported.   It works well on Linux.  It usually works
> on Cygwin.  It has often stopped working on MinGW / MSYS.  Autoconf cannot
> build on MSVC at all.

Exactly.

>  - Brandon won't chase complicated Autoconf problems.  Felix might.

If absolutely necessary.

>  - Patches or solutions for Autoconf bugs are certainly welcome.

Indeed.

>  - Brandon won't accept changes that fix Autoconf but break CMake.  Nor,
> changes that improve Chicken when built with Autoconf, but not with CMake.
> A lot of effort has been put into unifying the 2 builds, so that everyone
> can eventually migrate to CMake.  Not looking for people to run off in the
> Autoconf-only direction anymore.

A lot of work it was. I wouldn't put it that harshly, but getting a sane build
environment working is certainly prefered than muddling with m4 macros
or obsolete libtool versions. Unfortunately autotools is still kind of standard,
so if possible I will try to keep that build working, somehow (but actually
Brandon did a good lot himself, while unifying the builds).


cheers,
felix

--
http://galinha.ucpel.tche.br:8081/blog/blog.ssp