[CMake] autoconf and cmake

[Brandon J. Van Every]

Wojciech Jarosz wrote:
> Right. But other than the transitioning reason, is there any benefit
> to using autoconf in conjunction with CMake, as opposed to using CMake
> alone?

None.  Autoconf is a complete royal PITA.  Avoid it like the plague.  I 
didn't want to become an Autoconf expert... it was politically necessary 
to get everyone migrated to CMake.  The only area where Autoconf is 
better than CMake, is its documentation is much more thorough.  Of 
course, there's so much more horror to document, everything being split 
between Automake, Autoconf, GNU Make, Libtool, and m4.  You can get away 
with less documentation when your architecture is fundamentally cleaner 
and more integrated.

> Also, would the general scenario be to use autoconf to pass
> settings to CMake, or the other way around?
>

We don't pass settings from one to the other.  They are independent 
build systems.  They do share common .h and .in files, and each has 
their own way of generating those files.  It's important that both 
builds generate the same results when you're doing a migration.  A lot 
of the work was rationalizing the Unix and Windows builds so that they 
all used the same mechanisms and header files.

When we make a Chicken distribution, CMake is responsible for that.  It 
does all the inventorying and is the canonical method for building a 
distro.  We have an Autoconf method for doing it also, but I'm not 
maintaining it, so I don't know if it works.  I don't want it to work, I 
want it to die.  Anyways, when using CMake to build a distro, we do fire 
up Autoconf via autogen.sh so that the distro will have all the 
./configure files it needs and so forth.  This is a completely 
independent subtask, we don't pass any options.


Cheers,
Brandon Van Every