[CMake] Newbie questions

[William A. Hoffman]

At 03:15 PM 11/4/2004, Jeff Squyres wrote:
>Greetings!
>
>We are considering changing a relatively large software project away from the GNU tool suite (Autoconf, Automake, Libtool), and cmake was suggested to us.  I've downloaded it, played with it a little bit, read through the documentation and FAQ, and have looked through the last month or two of activity here on the mailing list.  It is my impression that cmake replaces these three tools by doing per-system tests, traversing directories, compiling source files, and building libraries and applications.  It does this by analyzing all the CMakeList.txt files and emitting "native" build instructions (such as VC++ projects, makefiles, etc.).
>
>Needless to say, I'm still quite the cmake newbie.  I hope that this is the appropriate forum to ask some newbie questions -- please feel free to redirect me to documentation, old posts on the lists, or other places that I can just got RTFM and not bother people about them.  I didn't see these questions answered, but it's quite possible that I missed them somewhere:
>
>1. Similar to some prior posts, we have a large software library that is built up from a large number of subdirectories (a whole tree of subdirectories, actually).  With Automake/Libtool, we build one library per directory and then "roll them up" into One Big Library at the end (so that the user does "-lWholeShebang", as someone previously posted here).

Currently, this is not directly supported by cmake.  CMake is good at creating lots of libraries, but
not in creating the WholeShebang.   You can create the WholeShebang with a single ADD_LIBRARY at
the top of the project that uses sources from the sub-directories.  However, you will not be able to make
in each sub-directory.  You may be able to create all the sub-libs, and then add the object files to
a WholeShebang library.  However, there are some issues with this working cross platform.  For instance,
on windows you have to have .def files or declspec(import/export) stuff in the code.  Usually, that
has ifdefs for each library.  


>I don't actually care about making a library in each subdirectory (we only do that because it is The Automake/Libtool Way), but being able to invoke "make" in each subdirectory is quite a useful thing.  What is the canonical cmake way having lots of source files dispersed throughout an entire tree (some of which may be conditionally compiled, depending on architecture, etc.) compiled into a single, top-level library?
>
>2. Automake provides two extremely useful targets that I don't see supported in cmake: "uninstall" and "dist".
>
>2a. Since "install" is supported, would it be difficult to implement "uninstall"?

It should not be that hard to implement, just not done yet.

>2b. "dist" is also quite useful -- it rolls up all the source files that it knows about (and any additional files like README that you can tag to be included) and makes a perfect tarball suitable for distribution (ensuring all the permissions are correct, vim/emacs backup files are excluded, etc.).
>
>Are there any plans to support a "dist"-like target that makes a tarball suitable for distribution?

There are plans to add distribution features to cmake in 2005.


>3. Waving my hands and assuming that I can somehow make a tarball that I can distribute to users, do the users need to have cmake installed to build it?  It's not 100% clear to me from reading all the docs and whatnot.  For example, if I run "cmake" on my development tree (such that it makes makefiles) and tar that up, is that suitable for users with a wide variety of POSIX platforms?  More specifically: when I run "cmake", does it make a configuration for *that specific machine*, or is it suitable for any machine that supports "make"?
>
>For example, our code needs to know if the system natively supports asprintf().  If it does, a #define zeros out a bunch of our code; if it doesn't, that #define activates a bunch of things in our code.  If I run "cmake" and tar up the results on a machine that supports asprintf(), what happens if someone untarrs and runs "make" on a platform that doesn't?
>
>Even more specifically: with my userbase, I cannot guarantee that they will have cmake installed.  Indeed, it is highly likely that they will not.  One of the nice things about the GNU tools is that users don't need to have Automake/Autoconf/Libtool installed to build an Automake/Autoconf/Libtool-produced tarball.  Is the same true with cmake?

To build from source, your users will have to install cmake.   The makefiles and system introspection
information is not portable from machine to machine.


>4. How good is cmake's support for shared libraries?  One of the main reasons we use Libtool is because it knows how to build shared libraries for a *lot* of different compilers on *lots* of different systems (including the wide variety of compilers available for the Linux platform).  What platforms / compilers does cmake support building shared libraries for?


Here are the platforms tested each night:

http://www.cmake.org/Testing/Dashboard/20041104-0100-Nightly/Dashboard.html
The tests include shared libraries.


-Bill