[CMake] Example using ExternalProject for configure+make and/or Win32?
Brian Davis
bitminer at gmail.com
Thu Aug 19 23:14:42 EDT 2010
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 <cliffyapp at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100819/c57f55b5/attachment-0001.htm>
More information about the CMake
mailing list