I am posting this back to cmake so others can follow along. I too use gmail and often forget the reply all.
On Thu, Aug 19, 2010 at 9:11 PM, Clifford Yapp <cliffy...@gmail.com> wrote: > Um... if you mean "CMakeified" in the sense of them having CMake files > for building, no... my understanding was that you don't really need > ExternalProject logic if the source in question has a CMakeLists.txt > file? - at least, I haven't needed it in those cases. zlib and libpng > I can both build and use to build other code in the same project with > ADD_SUBDIRECTORY and some variable setting (a very cool feature!) > > some do some do not has been my experience. Some have forced me to use add_subdirectory (boost) and others work best with ExternalProject_ADD (vtk vtkedge itk). Yes if source in question has CMakelist.txt then it is in my terms "CMakeified". I have used externalproject_add and add_subdirectory, but my mileage has varied based on how it was written. In my opinion add_subdirectory and externalproject_add are effectively broken due > I may be thinking about this wrong, but here's the specific situation > which prompted the question: > > I have in my source tree local checkouts of tcl and tk: > > src/other/tcl > src/other/tk > > These trees use autotools to build - they have no knowledge of CMake. > What I had hoped to do was use ExternalProject to trigger the > ./configure process as part of the CMake configure and the make > processes as a product of the CMake generated make files, or on WIN32 > incorporate the Microsoft Visual Studio project files into its own > project output - have I mis-understood it's purpose? > > from : http://public.kitware.com/pipermail/cmake/2010-January/034908.html specifically -snip- > as: > > C:\projects\NIH2009\source\branches\trunk\platform\tools\cmake-2.8.0-win32-x86\bin>cmake > --help-module ExternalProject > > cmake version 2.8.0 > ExternalProject > Create custom targets to build projects in external trees > > The 'ExternalProject_Add' function creates a custom target to drive > download, update/patch, configure, build, install and test steps of > an > external project: > > ExternalProject_Add(<name> # Name for custom target > [DEPENDS projects...] # Targets on which the project > depends > [PREFIX dir] # Root dir for entire project > [LIST_SEPARATOR sep] # Sep to be replaced by ; in cmd > lines > [TMP_DIR dir] # Directory to store temporary files > [STAMP_DIR dir] # Directory to store step timestamps > #--Download step-------------- > [DOWNLOAD_DIR dir] # Directory to store downloaded > files > [DOWNLOAD_COMMAND cmd...] # Command to download source tree > [CVS_REPOSITORY cvsroot] # CVSROOT of CVS repository > [CVS_MODULE mod] # Module to checkout from CVS repo > [CVS_TAG tag] # Tag to checkout from CVS repo > [SVN_REPOSITORY url] # URL of Subversion repo > [SVN_REVISION rev] # Revision to checkout from > Subversion repo > [URL /.../src.tgz] # Full path or URL of source > #--Update/Patch step---------- > [UPDATE_COMMAND cmd...] # Source work-tree update command > [PATCH_COMMAND cmd...] # Command to patch downloaded source > #--Configure step------------- > [SOURCE_DIR dir] # Source dir to be used for build > [CONFIGURE_COMMAND cmd...] # Build tree configuration command > [CMAKE_COMMAND /.../cmake] # Specify alternative cmake > executable > [CMAKE_GENERATOR gen] # Specify generator for native build > [CMAKE_ARGS args...] # Arguments to CMake command line > #--Build step----------------- > [BINARY_DIR dir] # Specify build dir location > [BUILD_COMMAND cmd...] # Command to drive the native build > [BUILD_IN_SOURCE 1] # Use source dir for build dir > #--Install step--------------- > [INSTALL_DIR dir] # Installation prefix > [INSTALL_COMMAND cmd...] # Command to drive install after > build > #--Test step--------------- > [TEST_BEFORE_INSTALL 1] # Add test step executed before > install step > [TEST_AFTER_INSTALL 1] # Add test step executed after > install step > [TEST_COMMAND cmd...] # Command to drive test > ) > > The *_DIR options specify directories for the project, with default > directories computed as follows. If the PREFIX option is given to > ExternalProject_Add() or the EP_PREFIX directory property is set, > then > an external project is built and installed under the specified > prefix: > > TMP_DIR = <prefix>/tmp > STAMP_DIR = <prefix>/src/<name>-stamp > DOWNLOAD_DIR = <prefix>/src > SOURCE_DIR = <prefix>/src/<name> > BINARY_DIR = <prefix>/src/<name>-build > INSTALL_DIR = <prefix> > > Otherwise, if the EP_BASE directory property is set then components > of > an external project are stored under the specified base: > > TMP_DIR = <base>/tmp/<name> > STAMP_DIR = <base>/Stamp/<name> > DOWNLOAD_DIR = <base>/Download/<name> > SOURCE_DIR = <base>/Source/<name> > BINARY_DIR = <base>/Build/<name> > INSTALL_DIR = <base>/Install/<name> > > If no PREFIX, EP_PREFIX, or EP_BASE is specified then the default is > to set PREFIX to "<name>-prefix". Relative paths are interpreted > with > respect to the build directory corresponding to the source directory > in which ExternalProject_Add is invoked. > > If SOURCE_DIR is explicitly set to an existing directory the project > will be built from it. Otherwise a download step must be specified > using one of the DOWNLOAD_COMMAND, CVS_*, SVN_*, or URL options. > The > URL option may refer locally to a directory or source tarball, or > refer to a remote tarball (e.g. http://.../src.tgz). > > The 'ExternalProject_Add_Step' function adds a custom step to an > external project: > > ExternalProject_Add_Step(<name> <step> # Names of project and > custom step > [COMMAND cmd...] # Command line invoked by this step > [COMMENT "text..."] # Text printed when step executes > [DEPENDEES steps...] # Steps on which this step depends > [DEPENDERS steps...] # Steps that depend on this step > [DEPENDS files...] # Files on which this step depends > [ALWAYS 1] # No stamp file, step always runs > [WORKING_DIRECTORY dir] # Working directory for command > ) > > The command line, comment, and working directory of every standard > and > custom step is processed to replace tokens <SOURCE_DIR>, > <BINARY_DIR>, > <INSTALL_DIR>, and <TMP_DIR> with corresponding property values. > > The 'ExternalProject_Get_Property' function retrieves external > project > target properties: > > ExternalProject_Get_Property(<name> [prop1 [prop2 [...]]]) > > It stores property values in variables of the same name. Property > names correspond to the keyword argument names of > 'ExternalProject_Add'. > -end snip-- there is : > [CONFIGURE_COMMAND cmd...] # Build tree configuration command so may be this works. I have not used it so I can not speak to it. problem will be if on Windows systems is finding an autotools that would work such as cygwin or msys. As far a documentation on ExternalProject_ADD, the fact that we must use the command line to get documentation speaks volumes how difficult it can be to learn this command. There is also a kitware pdf ( http://www.kitware.com/products/archive/kitware_quarterly1009.pdf) which made some vague refrences to ExternalProject_ADD. I hope others could chime in that know the command better. If stuck do what I do and look through the CMake source code... best documentation there is... on how it *realy* works.
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
