On 2008-12-27 18:21-0500 Naram Qashat wrote:
[...] my next question would be what the best way is to get CMake to coexist alongside an existing Autotools-based build system without breaking either one. Is it just a matter of having CMake's CMakeLists.txt files in place without touching the existing Autotools related files, or is there more to it than that?
That's about it since the CMakeLists.txt name obviously does not clash with autotools filenames. List files and cmake modules that are accessed by CMakeLists.txt files using the "include" and find_package commands normally have a dedicated subdirectory pointed to by CMAKE_MODULE_PATH so there is no chance for a nameclash with autotools files in that case as well. One minor potential nameclash to worry about is Autotools has template files for configured files called FILENAME.in where FILENAME is the name of the file that is configured by autotools. Often those template files can simply be shared by CMake to configure files as well using appropriately named assignment of CMake variables and the @ONLY configure_file signature file. However, sometimes the template files cannot be shared because you may find you want to do configuration (e.g., with #cmakedefine VAR) that is CMake specific or perhaps you want to configure more then your autotools build system currently does. In that "unshared template" case you will have to pick a different template file name for the CMake case. We used FILENAME.cmake. Now that autotools is gone I will probably change all such instances to FILENAME.in for consistency with my other CMake template files that were originally shared by autotools. Of course, under CMake you have complete control of the template file name and configured file name, but that latter file name is normally the same as the name of the configured file in the autotools case. An important point is you should advise your CMake build-system users to always use a separate build tree dedicated to CMake-based build system results; you obviously don't want files configured or built with your autotools-based build system to be mixed in with files configured or built with your CMake-based build system. In sum, autotools-based and CMake-based build systems can co-exist quite peacefully for the same software project if you are aware of the potential nameclash issues for template files in the source tree and the horrendous nameclash issues in the build tree if users didn't keep that build tree totally separate from autotools-generated build results. 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