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
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
