[CMake] Newbie questions

[Andy Cedilnik]

Hi Jeff,

On Thu, 2004-11-04 at 15:15, Jeff Squyres wrote:
> 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.).

Sounds like a good idea. 

> 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?

If I want to achieve this, I do something like:

SET(srcs
  Part1/src1.c
  Part1/src2.c
  Part1/src3.c
  Part2/src1.c
  Part2/src2.c
  Part2/src3.c
  ...
  PartN/src1.c
  PartN/src2.c
  PartN/src3.c
)

ADD_LIBRARY(WholeShebang ${srcs})

The object files will be in subdirectories Part1, Part2, ...

You can also specify full path to sources such as:

SET(srcs
  ${CMAKE_CURRENT_SOURCE_DIR}/Part1/src1.c
...
)

> 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"?

There is install manifest (install_manifest.txt), which can be used to
construct uninstall target. I consider uninstall to be dangerous and so
I did not put it in CMake. If there is enough demand for it I might
consider, but for now you can actually do it in your project:

Something like:

Create file:
cmake_uninstall.cmake.in, which looks like this:

FILE(READ "@CMAKE_CURRENT_BINARY_DIR@/install_manifest.txt" files)
STRING(REGEX REPLACE "\n" ";" files "${files}")
FOREACH(file ${files})
  MESSAGE("File: [${file}]")
  EXEC_PROGRAM("@CMAKE_COMMAND@" ARGS "-E remove \"${file}\"")
ENDFOREACH(file)

Then in your toplevel CMakeLists.txt you add:

CONFIGURE_FILE(
"${CMAKE_CURRENT_SOURCE_DIR}/cmake_uninstall.cmake.in"
"${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake")
ADD_CUSTOM_TARGET(uninstall "${CMAKE_COMMAND} -P
"${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake")

There may be typos, but you get the idea.

> 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?

We are working on that feature, but it will take some time.

> 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?

Unlike Auto* tools, you do need CMake installed on the system. CMake is
however extremely small and does not depend on anything, so asking
developers to download CMake is a small price. We do provide CMake
binaries for substantial amount of platforms.

> 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?

We do not have any problems with shared libraries. For a subset of
platforms on which most of CMake features are tested on the nightly
bases, you can check CMake, ITK, VTK, ParaView, and VXL dashboards:
http://public.kitware.com/dashboard.php
and
http://www.cs.rpi.edu/research/groups/vxl/Testing/Dashboard/MostRecentResults-Nightly/Dashboard.html

			Andy