[CMake] autoconf: Does it meet these cross-platform goals?

[Brandon J. Van Every]

Matt England wrote:
> I write general questions about build-system options below.  
> CMake-specific questions:
>
> Can CMake integrate with my existing, gnu-make based Makefiles without 
> having to rewrite their logic?
No.  CMake can perform essentially the same functions as GNU Autoconf.  
It is not a drop-in replacement for GNU Autoconf, it makes no effort 
whatsoever to be compatible with Autoconf.  You will have to do things 
the way CMake does them.  Translating from Autoconf to CMake is 
straightforward, but you do have to learn CMake, and learning anything 
takes time.

Me personally, I was doing Autoconf so long ago that I don't remember 
any of it now.  I've gone up a lot of the CMake learning curve, so I'm 
approaching the Autoconf --> CMake translation problem from the opposite 
end.  To me, Autoconf is a big hairy PITA because I have no recent 
experience with, plus I think it's inherently convoluted.  YMMV if 
you're already an Autoconf guru.  I consider CMake architecture to be 
fairly if not perfectly consistent, and it's getting better all the 
time.  I strongly recommend the CVS development version CMake 2.3 as it 
has a lot of functionality over CMake 2.2 that will make your life 
easier.  The official CMake release 2.4 is supposed to be out in a few 
weeks, so when that comes, you'll want that.  You can get started with 
2.3 if you're not averse to compiling from source.  You can also of 
course start with 2.2, and depending on the scale of your project and 
how fast you're working, you may not hit any "But... but... but I need 
it to do *this* !" problems until 2.4 ships.

> Can CMake generate autoconf-like "configure files?
>
CMake is not based on shell scripts.  CMake is more inclusive of 
operating systems than Autoconf; it is not trying to ram a UNIX 
environment down everyone's throat.  It is well supported on Unix, 
Windows, and Mac OS X.  Your users will have to install CMake in order 
to use CMake.  Installing CMake is rather trivial.

CMake generates native builds for many different compilers.  For 
instance, on Unix it will cough up Makefiles for you.  On Windows it can 
cough up all the different strains of Visual C++ build files for you, or 
NMake, or MinGW, or Cygwin, or Borland, and I think even Watcom now.  
This is, frankly, why CMake is superior to Autoconf.  From a "we want 
true platform neutrality" rather than a "we want GNU Nazis to take over 
the world and make everything Unix" perspective.  The most important 
thing about CMake, whatever its quirks, shortcomings, and learning 
curves, is it works as advertized for this problem.
>
> 1) Ensure the source packages can build on all systems
> 2) Ensure the application (binary) packages run on all supported systems
> 3) Ensure libraries we deliver integrate properly with other software 
> projects
Kitware also has an open source thingy called CTest, Dart, and "the 
dashboard" which I know little about.  Look into those for your testing 
concerns.

>
>
> For what it's worth: the external libraries (besides "standard" system 
> libraries) that we currently use include but may not be limited to the 
> following: various Boost-C++ libraries, OpenSSL, BZip2, libpqxx, 
> Xerces-c, and optionally ACE 
> (<http://www.cs.wustl.edu/~schmidt/ACE.html>), libcurl, and xmlrpc-c.
>
> Up until now, we were including each library (and its associated 
> header files) from the above toolset in a Subversion-controlled 
> "external" directory for each platform (eg, one for MinGW, Fedora, 
> RHEL, Debian, etc).  However, we're finding that some boost libs don't 
> work for all debian3.1 systems, etc.  I suspect we are going to run 
> into this problem more and more over time, and as such we need to let 
> system in question provide the library that's compatible with said 
> system (in the aforementioned case: let Debian's apt download/build 
> the right boost library).  Is my understanding correct?
Someone around here wanted to CMakeify Boost.  That's his personal 
project; it's exceedingly unlikely that the Boost people will ever be 
interested in the work.  CMake can build your own projects.  It's never 
going to supplant the build system of an external, mature project.  Not 
until those guys are sick to death of their build system and looking for 
a better way.  For some projects, CMake is the better way.  For other 
projects, they're getting along fine with Autoconf and you're not going 
to convince them to switch.  We have a mailing list called CMake-Promote 
about getting people to switch.

I wonder if CTest / Dart are the appropriate tools for your external 
build problems.

>
> However, I doubt the Makefile system will be robust enough to handle 
> the nuances of truly cross-platform builds; maybe that's an 
> understatement.  The tried-and-true tool to address this seems to be 
> autoconf, and I'm currently gearing myself up to author some 
> autoconf-based control files.  However, autoconf does not appear to 
> address non-MinGW Windows environments.
It never will.  The GNU Project is openly hostile to having Autoconf 
work well with Visual C++.  I have been on their mailing list, and have 
offered to collect up sources from no less than *2* projects that 
provide near-ready front-ends for VC++, so that Autoconf could handle it 
transparently.  Their answer: "Please go away.  It harms the GNU 
Project."  They are exceedingly political and will never, ever provide a 
platform neutral solution.

I found CMake after going up the full learning curve of what Autoconf 
can't / won't do.

>   For that reason, my project is currently supporting only MinGW in 
> Windows environments.  However, I'd like to be able to "single-source 
> control" the build process for non-autoconf-supported systems like 
> VisualStudio systems (and to a lesser extent CodeBlocks, Dev-C++, 
> etc...although they are a safer bet to read GNUmake Makefiles) in the 
> future.  bakefile is the only thing that I've seen that yet supports 
> this approach.  CMake (CMake?) might, but I'm not sure about VStudio; 
> further, CMake requires that all my developer-users change their usage 
> patterns (from './configure && make && make install') and to build and 
> use CMake...and I'm not yet inclined to change this paradigm.
This is a perception issue.  Let me be frank: VC++ users *hate* your 
stinky little Unix shell scripts and command lines.  Do you want 
cross-platform or do you want to force everyone to do things The Unix 
Way [TM] ?  CMake works.  Autoconf doesn't work.  The price is making 
the lazy ass users do something other than type ./configure.  So, 
consider how many users on each platform you have, and how many you'd 
like to have.

Bear in mind, I don't make my harsh comment from a lack of perspective.  
My primary build environment is MinGW / MSYS.  But I spent 2 years 
slogging it out trying to get cross-platform stuff to build with VC++.  
I know how VC++ oriented developers think, I've been one of those myself 
for enough of my so-called career.

>
> A note about autoconf:  I'm hoping it provides a *supplement* to my 
> existing Makefile system, instead of replacing such system with new, 
> auto-generated makefiles, etc.  (For this and possibly other reasons 
> I'm steering clear of using automake, as per experiences like these: 
> <http://subversion.tigris.org/hacking.html#configury>).  I'm a control 
> freak about my build-control process, and I don't want some automated 
> tool specifying what my build rules and dependencies are.
Seems like in CMake I've manually specified all my dependencies.  I 
mostly use CMake's built-in build rules, but you can specify your own 
custom build rules if you like.  For instance, I have a custom build 
rule for Chicken Scheme compilation because CMake doesn't inherently 
have that.  If you want to be anal retentive, I'm sure CMake can 
accomodate you. Also CMake doesn't generate the "vast amounts of 
inscrutable scripting stuff" that Autoconf does.  I mean when I look at 
a ./configure or a ./config.status my head just spins.

> Rather, I want autoconf (or some tool that replaces it) to simply make 
> sure that the build environment (on said machine) is sufficient and 
> then set the make variables accordingly as inputs to my existing 
> make/Makefile process.  Is this the way it works...or at least can 
> work...with autoconf?  Another way to ask this: can autoconf 
> essentially be made a "slave" to the Makefile.in file?
I don't see that as an adviseable architecture for cross-platform work, 
but yes you could do it.  For instance I just wrote a script that 
detects extant Chicken Scheme installations.  Detect, test, and variable 
substitution can all be done with CMake.

>
> Separately:  what does one do about Windows?  What about other 
> "non-Unix" operating systems like VMS?
For MinGW, one uses Dev-Cpp to get some packaging sanity.  A lot of 
things you can get pre-built; what you can't, isn't too hard to compile 
from source *if they ever bothered with MinGW*.  For Cygwin, library 
dependencies are a non-issue, everything is well packaged.  For VC++, 
you're screwed.  You can rely on big packages, i.e. Python, SDL, to have 
VC++ binaries available, so you'd just grab those from whatever 
website.  But the litanies of smaller stacked open source libraries, 
like is common in the Unix world, is a really serious problem for a VC++ 
oriented developer.  You can spend forever trying to build all that 
stuff.  My advice is, don't.  Reduce your external dependencies.

Some people have significant financial resources at their disposal to 
solve build problems.  In that case, you could CMakeify everything that 
you must have and isn't doing what you want.  But this is a very 
"corporate big bucks" solution to the problem.  Just noting that in the 
limit, it's all open source.

>
> Do .msi-like installation packages do the work that of Debian's apt in 
> that said system will automatically download missing library 
> dependencies?  I highly doubt it.
No.  CMake is not a package management system.  I don't see any 
reasonable way that it could do that cross-platform.  Consider how many 
package management systems are available on Linux alone!

>   Must my project include all the binary packages for my external 
> libs/bins (eg, OpenSSL, PostgreSQL) in these distributions?  (For what 
> it's worth, our project currently supports MinGW-based Windows 
> distributions of our stuff.)
Only if you want to be sure that everything works.  ;-)  You can tell 
all your users to install their own library dependencies.  This often 
results in irreproducible builds.  If it were my project, I'd put each 
and every bloody library under source control.  I recommend the Darcs 
distributed source control system for such problems.  
http://abridgegame.org/darcs/  The main advantage of Darcs is it has a 
consistent patch theory, which allows patches to be merged in almost any 
order.  Also, each local Darcs folder is its own repository, there is no 
central notion of a server.  This means lotsa people can work on 
slightly different versions of everything, they don't block each other, 
and Darcs can actually handle merging the results.  Very important 
capability in an open source context.

>
> We want to provide the core functionality of our project's technology 
> as an "embed-able" library (either in static or 
> dynamic-shared-object/dll fashion).
>
> The libtool section of the autoconf manual 
> (<http://www.gnu.org/software/autoconf/manual/index.html>), quoted 
> below, appears to sum up the issues surrounding this...I guess.  I 
> have to take libtool's word for it, for I have to experience the 
> library distribution problems in our project that libtool says will 
> happen.  But if this helps, then we'll do it.  Do any alternatives exist?
CMake doesn't use libtool.  It has various shared library capabilities.  
Some people have had issues in corner cases for CMake 2.2.  This 
resulted in more functionality for development 2.3 and 
soon-to-be-released 2.4.  I'm not a shared library guru yet.  The issues 
I've run into were mostly about library name collisons and directory 
installations.  2.3 solved all my problems.  Exactly what kind of 
dynamic library I'm building for broadest compatibility, is ground I 
haven't really worked through yet.  Windows .dll formats are a mess, as 
the following webpage illustrates:
http://www.geocities.com/yongweiwu/stdcall.htm
For now my philosophy is "better build everything with the same compiler."


Cheers,
Brandon Van Every