Let me try to clarify some terminology. The source tree is where source files (*.c, etc.) and configuration files (CMakeList.txt, etc.) live.
The build tree is where you build the software. It contains everything that is configured or built. It's got a lot of files in it (e.g., *.o) that are essential to the build of executables or libraries, but which are not of interest to pure users of the software. It is possible to do an in-source build where the build tree is superimposed on the source tree, but it is just easier to keep the two separate since it allows you to entirely remove your build tree and start over without molesting your source tree. The install tree is where you install the subset of the build tree that is used by pure users. So it consists normally of just executables, libraries, and documentation. The various CMakeLists.txt files that are in the source tree specify exactly what is to be put in the install tree. The install tree should be kept entirely separate from the source tree and build tree. A source package normally just contains a packager-specified subset of the source tree (e.g., the packager would want to skip .svn or CVS directories) in some packager-specified format (e.g., compressed tarball). A software packager can generate source packages of his software using CMake (via CPack). User's of source packages obviously have to build the packaged software for themselves using CMake, but that gives them a lot of freedom since CMake configures the build for the special circumstances of their particular system. For example, it is very good at finding 3rd-party libraries required for the build that happen to be in non-standard locations or modifying the build (e.g., dropping parts of it) if certain 3rd-party components are not found. A binary package contains everything that is in the install tree in some packager-specified format (e.g., compressed tarball). A software packager can generate binary packages of his software using CMake (via CPack). User's of binary packages don't have to build anything (they just use the executables and libraries that are supplied), but such binary packages demand a lot in terms of standardization. For example, they normally expect 3rd-party libraries to be of the same version and in the same location for the user as they were for the packager. So binary packages are great if built for a standard environment like a particular Linux distribution, but if there is any variation in the standard (e.g., Debian versus RedHat), the departure from the expected standards leads to trouble, and the user is better off building the software from a source package. I hope this explanation helps to clear up some questions that have appeared in this thread. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
