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

Reply via email to