Re: [CMake] Build only what you need in third party libs
Here is the latest which includes wroking build of dcmtk NOTE the additon of
-DINSTALL_PREFIX=${INSTALL_PREFIX} as dcmtk required this move its install
eventhought CMAKE_INSTALL_PREFIX was specified. Boost is still not building
as boost wave and serialization do not build, but hey I guess 82 out of 84
packages isn't bad odds. Also not the removal of "in" in the foreach
block. An error on my part above.
The addition of BINARY_DIR ${BUILD_DIR}/ouput/bin/${PACKAGE} as suggested by
David works. Thanks David.
SET( THIRD_PARTY_PACKAGES
vtk-5.4.2
dcmtk-3.5.4
boost-cmake-1_41_0
)
foreach( PACKAGE ${THIRD_PARTY_PACKAGES} )
ExternalProject_Add(
${PACKAGE}
DOWNLOAD_COMMAND ""
SOURCE_DIR ${TOP}/source/cpp/lib/3rdParty/Win/${PACKAGE}
BINARY_DIR ${BUILD_DIR}/ouput/bin/${PACKAGE}
INSTALL_DIR ${INSTALL_PREFIX}
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${INSTALL_PREFIX}
-DINSTALL_PREFIX=${INSTALL_PREFIX}
)
endforeach( PACKAGE )
I just wanted to post and update with some corrections for those who may
find this useful.
--
Brian J. Davis
___
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
Re: [CMake] Build only what you need in third party libs
On Fri, Jan 29, 2010 at 4:07 PM, Brian Davis wrote:
> ExternalProject_Add does not like BINARY_DIR same for multiple packages...
> Why?
>
To avoid one package's output from clobbering another package's output. For
CMake built projects, for example, the BINARY_DIR is where CMakeCache.txt
ends up. There can only be one CMakeCache.txt in a directory, so there can
only be one project for each BINARY_DIR.
> SET( THIRD_PARTY_PACKAGES
> vtk-5.4.2
> dcmtk-3.5.4
>
> boost-cmake-1_41_0
> )
>
> foreach( PACKAGE in ${THIRD_PARTY_PACKAGES} )
>
> ExternalProject_Add(
> ${PACKAGE}
> DOWNLOAD_COMMAND ""
> SOURCE_DIR ${TOP}/source/cpp/lib/3rdParty/Win/${PACKAGE}
> BINARY_DIR ${BUILD_DIR}/ouput/bin
> INSTALL_DIR ${INSTALL_PREFIX}
> )
>
> endforeach( PACKAGE )
>
Instead of "BINARY_DIR ${BUILD_DIR}/ouput/bin", try:
BINARY_DIR ${BUILD_DIR}/${PACKAGE}
from VS Studio I get:
>
> 1>1>CMake Error at cmake_install.cmake:31 (FILE):
> 1>1> file cannot create directory: C:/Program Files (x86)/VTK/lib/vtk-5.4.
>
> and reading http:///www.kitware.com/products/archive/*
> kitware_quarterly1009*.*pdf* excerpt:
>
>
> Install step
> The INSTALL_DIR is underneath the calling project’s binary
> directory. Use INSTALL_DIR to specify a different location.
> Note that in addition to setting INSTALL_DIR, you also have
> to pass -DCMAKE_INSTALL_PREFIX or --prefix to the CMake
> or configure command. It is not used automatically in the
> configure step since not all projects follow this convention.
>
> # [INSTALL_DIR dir]
>
>
> My projects must fall into the "not all projects follow this convention",
> but wait Kitware makes vtk and Kitware makes Cmake. Is Kitware not
> following it's own convention here or is something else going on?
>
"Kitware projects" are built with CMake and all use CMAKE_INSTALL_PREFIX to
determine the install directory. You should use CMAKE_ARGS
-DCMAKE_INSTALL_PREFIX=${INSTALL_PREFIX}
for "Kitware projects"
>
> I also get when I build dcmtk:
>
> 1>CMake Error: The source
> "C:/projects/NIH2009/source/branches/trunk/source/cpp/lib/3rdParty/Win/dcmtk-3.5.4/CMakeLists.txt"
> does not match the source
> "C:/projects/NIH2009/source/branches/trunk/source/cpp/lib/3rdParty/Win/vtk-5.4.2/CMakeLists.txt"
> used to generate cache. Re-run cmake with a different source directory.
>
> Looks like there is some CMake cache cross mojonation going on here
This is because of using the same BINARY_DIR for multiple
ExternalProject_Add calls.
> I guess I'll try:
>
> ExternalProject_Add(
> ${PACKAGE}
> DOWNLOAD_COMMAND ""
> SOURCE_DIR ${TOP}/source/cpp/lib/3rdParty/Win/${PACKAGE}
> #BINARY_DIR ${BUILD_DIR}/ouput/bin
> INSTALL_DIR ${INSTALL_PREFIX}
> CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${INSTALL_PREFIX}
> )
>
> 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 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 co
Re: [CMake] Build only what you need in third party libs
ExternalProject_Add does not like BINARY_DIR same for multiple packages...
Why?
SET( THIRD_PARTY_PACKAGES
vtk-5.4.2
dcmtk-3.5.4
boost-cmake-1_41_0
)
foreach( PACKAGE in ${THIRD_PARTY_PACKAGES} )
ExternalProject_Add(
${PACKAGE}
DOWNLOAD_COMMAND ""
SOURCE_DIR ${TOP}/source/cpp/lib/3rdParty/Win/${PACKAGE}
BINARY_DIR ${BUILD_DIR}/ouput/bin
INSTALL_DIR ${INSTALL_PREFIX}
)
endforeach( PACKAGE )
from VS Studio I get:
1>1>CMake Error at cmake_install.cmake:31 (FILE):
1>1> file cannot create directory: C:/Program Files (x86)/VTK/lib/vtk-5.4.
and reading http:///www.kitware.com/products/archive/*kitware_quarterly1009*
.*pdf* excerpt:
Install step
The INSTALL_DIR is underneath the calling project’s binary
directory. Use INSTALL_DIR to specify a different location.
Note that in addition to setting INSTALL_DIR, you also have
to pass -DCMAKE_INSTALL_PREFIX or --prefix to the CMake
or configure command. It is not used automatically in the
configure step since not all projects follow this convention.
# [INSTALL_DIR dir]
My projects must fall into the "not all projects follow this convention",
but wait Kitware makes vtk and Kitware makes Cmake. Is Kitware not
following it's own convention here or is something else going on?
I also get when I build dcmtk:
1>CMake Error: The source
"C:/projects/NIH2009/source/branches/trunk/source/cpp/lib/3rdParty/Win/dcmtk-3.5.4/CMakeLists.txt"
does not match the source
"C:/projects/NIH2009/source/branches/trunk/source/cpp/lib/3rdParty/Win/vtk-5.4.2/CMakeLists.txt"
used to generate cache. Re-run cmake with a different source directory.
Looks like there is some CMake cache cross mojonation going on here
I guess I'll try:
ExternalProject_Add(
${PACKAGE}
DOWNLOAD_COMMAND ""
SOURCE_DIR ${TOP}/source/cpp/lib/3rdParty/Win/${PACKAGE}
#BINARY_DIR ${BUILD_DIR}/ouput/bin
INSTALL_DIR ${INSTALL_PREFIX}
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${INSTALL_PREFIX}
)
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 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_
Re: [CMake] Build only what you need in third party libs
On Thu, Jan 28, 2010 at 5:23 PM, Brian Davis wrote:
>
> Update: currently crying uncle ... and switching to ExternalProject_Add.
> CMake and the third party libs were simply not designed for this.
>
> Question on ExternalProject_Add above:
>
>
> ExternalProject_Add(
> DOWNLOAD_COMMAND ""
> CMAKE_ARGS
> -DMYPROJ_UBERBUILD:BOOL=OFF
> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}
> ...
> )
>
> I had in my project:
>
> SET( THIRD_PARTY_SRC_DIR 3rdParty/Win )
>
> add_subdirectory( ${THIRD_PARTY_SRC_DIR}/vtk-5.4.2 ./vtk-5.4.2 )
>
> and so I replaced it with:
>
> ExternalProject_Add(
> vtk-5.4.2
> DOWNLOAD_COMMAND ""
> SOURCE_DIR ${THIRD_PARTY_SRC_DIR}/vtk-5.4.2
> #SOURCE_DIR
> C:\projects\NIH2009\source\branches\trunk\source\cpp\lib\3rdParty\Win\vtk-5.4.2
> SOURCE_DIR /source/cpp/lib/3rdParty/Win/vtk-5.4.2
>
> )
>
> Where these lines are in a CMakeLists.txt file located at:
>
> C:\projects\NIH2009\source\branches\trunk\source\cpp\lib\CMakeLists.txt
>
> but I get the error in Visual Studio:
>
> 2>CMake Error: The source directory
> "C:/projects/NIH2009/source/branches/trunk/build/dvip4-Win64/cpp_source/lib/3rdParty/Win/vtk-5.4.2"
> does not appear to contain CMakeLists.txt.
>
> Note the prefixing of
> C:/projects/NIH2009/source/branches/trunk/build/dvip4-Win64/cpp_source/lib
>
> vtk is located at
> C:\projects\NIH2009\source\branches\trunk\source\cpp\lib\3rdParty\Win\vtk-5.4.2
>
> and project root CMakeLists.txt is at
> C:\projects\NIH2009\source\branches\trunk
>
>
>
> ExternalProject_Add(
> vtk-5.4.2
> DOWNLOAD_COMMAND ""
> SOURCE_DIR /source/cpp/lib/3rdParty/Win/vtk-5.4.2
>
> )
>
> and get:
>
> 2>CMake Error: The source directory
> "/source/cpp/lib/3rdParty/Win/vtk-5.4.2" does not appear to contain
> CMakeLists.txt.
>
> so I try:
>
> SOURCE_DIR /3rdParty/Win/vtk-5.4.2
>
> 2>CMake Error: The source directory "/3rdParty/Win/vtk-5.4.2" does not
> appear to contain CMakeLists.txt.
>
>
> so I try absolute path:
>
>
> ExternalProject_Add(
> vtk-5.4.2
> DOWNLOAD_COMMAND ""
> SOURCE_DIR
> C:\projects\NIH2009\source\branches\trunk\source\cpp\lib\3rdParty\Win\vtk-5.4.2
> }
>
> Ahhh the hacking... I am going to find my way out of this forest one day...
> and onto a desert.
>
> And now CMake finds the vtk goop. Now the question: Is there a project
> relative directory syntax to use here or is ExternalProject not like
> add_subdirectory in this regard?
>
>
Relative path use is probably not well-defined for ExternalProject_Add.
If, as you say:
"vtk is located at
C:\projects\NIH2009\source\branches\trunk\source\cpp\lib\3rdParty\Win\vtk-5.4.2
and
project root CMakeLists.txt is at C:\projects\NIH2009\source\branches\trunk"
Then I would construct a call to ExternalProject_Add in the project root
CMakeLists like this:
ExternalProject_Add(
vtk-5.4.2
DOWNLOAD_COMMAND ""
SOURCE_DIR
${CMAKE_CURRENT_SOURCE_DIR}/source/cpp/lib/3rdParty/Win/vtk-5.4.2
)
All _DIR type arguments in CMake should be specified as full absolute paths
unless there is documentation that tells you it's ok to use a relative path
name and what directory such values should be relative to...
For ExternalProject_Add, it's best to use full path names with "/"
separators for all _DIR parameters.
HTH,
David
___
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
Re: [CMake] Build only what you need in third party libs
Update: currently crying uncle ... and switching to ExternalProject_Add.
CMake and the third party libs were simply not designed for this.
Question on ExternalProject_Add above:
ExternalProject_Add(
DOWNLOAD_COMMAND ""
CMAKE_ARGS
-DMYPROJ_UBERBUILD:BOOL=OFF
SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}
...
)
I had in my project:
SET( THIRD_PARTY_SRC_DIR 3rdParty/Win )
add_subdirectory( ${THIRD_PARTY_SRC_DIR}/vtk-5.4.2 ./vtk-5.4.2 )
and so I replaced it with:
ExternalProject_Add(
vtk-5.4.2
DOWNLOAD_COMMAND ""
SOURCE_DIR ${THIRD_PARTY_SRC_DIR}/vtk-5.4.2
#SOURCE_DIR
C:\projects\NIH2009\source\branches\trunk\source\cpp\lib\3rdParty\Win\vtk-5.4.2
SOURCE_DIR /source/cpp/lib/3rdParty/Win/vtk-5.4.2
)
Where these lines are in a CMakeLists.txt file located at:
C:\projects\NIH2009\source\branches\trunk\source\cpp\lib\CMakeLists.txt
but I get the error in Visual Studio:
2>CMake Error: The source directory
"C:/projects/NIH2009/source/branches/trunk/build/dvip4-Win64/cpp_source/lib/3rdParty/Win/vtk-5.4.2"
does not appear to contain CMakeLists.txt.
Note the prefixing of
C:/projects/NIH2009/source/branches/trunk/build/dvip4-Win64/cpp_source/lib
vtk is located at
C:\projects\NIH2009\source\branches\trunk\source\cpp\lib\3rdParty\Win\vtk-5.4.2
and project root CMakeLists.txt is at
C:\projects\NIH2009\source\branches\trunk
ExternalProject_Add(
vtk-5.4.2
DOWNLOAD_COMMAND ""
SOURCE_DIR /source/cpp/lib/3rdParty/Win/vtk-5.4.2
)
and get:
2>CMake Error: The source directory "/source/cpp/lib/3rdParty/Win/vtk-5.4.2"
does not appear to contain CMakeLists.txt.
so I try:
SOURCE_DIR /3rdParty/Win/vtk-5.4.2
2>CMake Error: The source directory "/3rdParty/Win/vtk-5.4.2" does not
appear to contain CMakeLists.txt.
so I try absolute path:
ExternalProject_Add(
vtk-5.4.2
DOWNLOAD_COMMAND ""
SOURCE_DIR
C:\projects\NIH2009\source\branches\trunk\source\cpp\lib\3rdParty\Win\vtk-5.4.2
}
Ahhh the hacking... I am going to find my way out of this forest one day...
and onto a desert.
And now CMake finds the vtk goop. Now the question: Is there a project
relative directory syntax to use here or is ExternalProject not like
add_subdirectory in this regard?
--
Brian J. Davis
___
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
Re: [CMake] Build only what you need in third party libs
So I figured out the answer to: Can anyone point me on a path which would help me figure out what (global project settings) in dcmtk could be causing these kinds of changes in my unrelated nbody project? I removed (i.e. the force to use earlier version): # check required version of CMake CMAKE_MINIMUM_REQUIRED(VERSION 2.0) #IF(CMAKE_BACKWARDS_COMPATIBILITY GREATER 2.0.6) # SET(CMAKE_BACKWARDS_COMPATIBILITY 2.0.6 CACHE STRING "Latest version of CMake when this project was released." FORCE) #ENDIF(CMAKE_BACKWARDS_COMPATIBILITY GREATER 2.0.6) in dcmtk lib and the nbody app compiles. Why? Brian. ___ 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
Re: [CMake] Build only what you need in third party libs
Part 1 - Being resent in brokendown form due to 40kb limit on mail list
Continuing on with my attempt to build a project with includes 3rdParty Libs
I have run into a problem when adding library (using add_subdirectory(
pathtowherever/dcmtk dcmtk ) dcmtk (Dicom Toolkit) and building a CUDA test
application (nbody - from NVIDA SDK) as test to verity I could build both
using CMake.
I have the following line in one of my CMakeLists.txt files which I have
traced the issue down to.
add_subdirectory( ${THIRD_PARTY_SRC_DIR}/dcmtk-3.5.4 ./dcmtk-3.5.4 )
When I include this line the nbody app fails to build. When I remove it the
NBody app compiles.
The link error created when dcmtk is included in the project is:
1>Linking...
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
allocateNBodyArrays referenced in function "protected: virtual void __cdecl
BodySystemCUDA::_initialize(
int)" (?_initial...@bodysystemcuda@@mea...@z)
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
registerGLBufferObject referenced in function "protected: virtual void
__cdecl BodySystemCUDA::_initialize(int)" (?_initial...@bodysystemcuda
@@mea...@z)
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
unregisterGLBufferObject referenced in function "protected: virtual void
__cdecl BodySystemCUDA::_finalize(void)" (?_final...@bodysystemcuda
@@MEAAXXZ)
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
deleteNBodyArrays referenced in function "protected: virtual void __cdecl
BodySystemCUDA::_finalize(void)" (?_final...@bodysystemcuda@@MEAAXXZ)
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
setDeviceSoftening referenced in function "public: virtual void __cdecl
BodySystemCUDA::setSoftening(float)" (?setsoften...@bodysystemcuda@@uea...@z
)
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
integrateNbodySystem referenced in function "public: virtual void __cdecl
BodySystemCUDA::update(float)" (?upd...@bodysystemcuda@@uea...@z)
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
copyArrayFromDevice referenced in function "public: virtual float * __cdecl
BodySystemCUDA::getArray(enum BodySystem::BodyArray)"
(?getar...@bodysystemcuda@@ueaapeamw4bodyar...@bodysystem@@@Z)
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol
copyArrayToDevice referenced in function "public: virtual void __cdecl
BodySystemCUDA::setArray(enum BodySystem::BodyArray,float const *)"
(?setar...@bodysystemcuda@@ueaaxw4bodyar...@bodysystem@@p...@z)
1>bodysystemcuda.obj : error LNK2019: unresolved external symbol threadSync
referenced in function "public: virtual void __cdecl
BodySystemCUDA::synchronizeThreads(void)const "
(?synchronizethre...@bodysystemcuda@@UEBAXXZ)
1>C:\projects\NIH2009\source\branches\brian\build\Windows-6.1\ouput\bin\Debug\nbody.exe
: fatal error LNK1120: 9 unresolved externals
1>Build log was saved at
"file://c:\projects\NIH2009\source\branches\brian\build\dvip4-Win64-broken\cpp_source\app\nbody\nbody.dir\Debug\BuildLog.htm"
1>nbody - 10 error(s), 0 warning(s)
Which is a linker error where extern "C" files cannot be found. The
inclusion of a third party lib affects the project globally. Now
conversations above imply that CMake was never designed for this type of use
case. I have already had to change boost cmake build and will be submitting
my patch to that mailing list. It appears as though now dcmtk does not play
nice either. There are differences in the files... some I expect and others
I did not.
A simple file diff showing the files affected between just the project with
nbody (only nbody) and the project with dcmtk (nbody and dcmtk) included
are:
Files dvip4-Win64-working/ALL_BUILD.vcproj and
dvip4-Win64-broken/ALL_BUILD.vcproj differ
Files dvip4-Win64-working/CMakeCache.txt and
dvip4-Win64-broken/CMakeCache.txt differ
Files dvip4-Win64-working/CMakeFiles/CMakeDetermineCompilerABI_C.bin and
dvip4-Win64-broken/CMakeFiles/CMakeDetermineCompilerABI_C.bin differ
Files dvip4-Win64-working/CMakeFiles/CMakeDetermineCompilerABI_CXX.bin and
dvip4-Win64-broken/CMakeFiles/CMakeDetermineCompilerABI_CXX.bin differ
Files dvip4-Win64-working/CMakeFiles/generate.stamp.list and
dvip4-Win64-broken/CMakeFiles/generate.stamp.list differ
Only in dvip4-Win64-broken/CMakeFiles: INSTALL_force.rule
Files dvip4-Win64-working/CMakeFiles/TargetDirectories.txt and
dvip4-Win64-broken/CMakeFiles/TargetDirectories.txt differ
Files dvip4-Win64-working/cpp_source/ALL_BUILD.vcproj and
dvip4-Win64-broken/cpp_source/ALL_BUILD.vcproj differ
Only in dvip4-Win64-broken/cpp_source/app/CMakeFiles: INSTALL_force.rule
Only in dvip4-Win64-broken/cpp_source/app/dicomserver/CMakeFiles:
INSTALL_force.rule
Only in dvip4-Win64-broken/cpp_source/app/dicomserver: INSTALL.vcproj
Only in dvip4-Win64-broken/cpp_source/app: INSTALL.vcproj
Only in dvip4-Win64-working/cpp_source/app/nbody: bodysystemcuda.linkinfo
Files
dvip4-Win64-working/cpp_source/app/nbody/CMakeFiles/generate.s
Re: [CMake] Build only what you need in third party libs
> > There are a block of these in tools/build/CMake/BoostConfig.cmake, feel > free to delete them. They were added a long ago, before anybody had > thought that one might try to build boost in a subdirectory like this. > Here again boost.cmake is being strange and difficult due to its (imv > misguided) attempts to emulate the strangeness and difficulty of bjam, > which itself originates in the strange and difficult boost dev. > community... > > I did this and it appears to work. I will report my successes and failures for others who are interested in the topic. dcmtk now builds in uber project. Thanks, Brian ___ 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
Re: [CMake] Build only what you need in third party libs
On Tue, Dec 22, 2009 at 11:29 AM, Brian Davis wrote: > > >> > There will never be an easy way to pull external projects directly into >>> a >>> > calling project because the external things are not even guaranteed to >>> be on >>> > disk yet at configure time of said calling project. >>> >>> >>> Yeah, kind of a chicken-egg problem... >>> >> >> Exactly. That's why we didn't try to solve that problem. If you have a >> chicken-egg problem to solve, you have to choose starting with a chicken or >> an egg, thereby alienating approximately 50% of your audience, even if you >> have good reasons for your choice. >> > > > I like cake. I like eating it too. Mmmm cake! > One could argue that CMake itself is simply a horrific misspelling of "Mmmm cake"... And that cmake-gui is like cmake with frosting. Cmake may not *know where the third party is when it configures*, but it > *knows where it will be*. The build will/could take care of the rest. > Correct? > I think "could" is fairly optimistic actually. It would be possible if you had perfect knowledge of the install tree of each and every project you're depending on. But some of the details are not known by CMake until after that project is built and installed. We allow people to write their own arbitrary stuff into their *Config.cmake files... so it ends up being arbitrary. And some external projects are actually not even built with cmake. (Gasp!) CMake will never provide the perfect solution to this problem. However, if you are willing to do the work necessary, it would certainly be possible for your project to pre-define stuff in such a way as to make it "do-able". It might not be fun, but it could be possible. :-) Good discussion on all this stuff today. This has been a fun day so far. Thanks to all of you who've participated, David ___ 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
Re: [CMake] Build only what you need in third party libs
On 22. Dec, 2009, at 17:29 , Brian Davis wrote: > > >>> There will never be an easy way to pull external projects directly into a calling project because the external things are not even guaranteed to >>> be on disk yet at configure time of said calling project. >>> >>> >>> Yeah, kind of a chicken-egg problem... >>> >> >> Exactly. That's why we didn't try to solve that problem. If you have a >> chicken-egg problem to solve, you have to choose starting with a chicken or >> an egg, thereby alienating approximately 50% of your audience, even if you >> have good reasons for your choice. >> > > > I like cake. I like eating it too. Mmmm cake! Cmake may not *know where > the third party is when it configures*, but it *knows where it will be*. > The build will/could take care of the rest. Correct? The 50% rule is how > Bush won the election (alienating half the audience - through Karl Rove > tactics)... we all know how that turned out :-) (this is a joke - and is > meant as such - don't read too much into it but has a half/50% serious part) No, it can't. When you run the cmake executable (either cmake-gui, cmake or ccmake), CMake does NOT know anything about the external project except what YOU declared. The project hasn't been downloaded, extracted, patched and configured so far, so CMake can't possibly find out which targets that project is going to build. Of course, CMake could do all these steps at configure-time, but that doesn't work nicely either, because every time the user changes the cache, this might re-trigger all of these steps. And it would slow down the configure step considerably. Michael ___ 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
Re: [CMake] Build only what you need in third party libs
> > There will never be an easy way to pull external projects directly into a
>> > calling project because the external things are not even guaranteed to
>> be on
>> > disk yet at configure time of said calling project.
>>
>>
>> Yeah, kind of a chicken-egg problem...
>>
>
> Exactly. That's why we didn't try to solve that problem. If you have a
> chicken-egg problem to solve, you have to choose starting with a chicken or
> an egg, thereby alienating approximately 50% of your audience, even if you
> have good reasons for your choice.
>
I like cake. I like eating it too. Mmmm cake! Cmake may not *know where
the third party is when it configures*, but it *knows where it will be*.
The build will/could take care of the rest. Correct? The 50% rule is how
Bush won the election (alienating half the audience - through Karl Rove
tactics)... we all know how that turned out :-) (this is a joke - and is
meant as such - don't read too much into it but has a half/50% serious part)
> So: there is one approach that's sort of a hybrid here, that I'll mention
> because it might be useful to consider.
>
> You could have a cmake option in your project that builds your project one
> of two ways: "as usual" or as the final link in a chain of
> ExternalProject_Add calls. I've done this and I know it works, but it's
> proprietary and I cannot point you to the source code. This technique,
> however, does make things hard to think about at times...
>
> Something like this in CMakeLists.txt:
> ==
> option(MYPROJ_UBERBUILD "If ON, build all prereqs first, then build me..."
> ON)
> if(uberbuild)
> include(BuildAllViaExternalProject.cmake)
> else()
> include(BuildJustMe.cmake)
> endif()
>
> And as the last thing inside BuildAllViaExternalProject.cmake:
> ==
> ExternalProject_Add(
> DOWNLOAD_COMMAND ""
> CMAKE_ARGS
> -DMYPROJ_UBERBUILD:BOOL=OFF
> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}
> ...
> )
>
>
> The net effect is that a project can build itself as an ExternalProject
> with the "clever (?)" use of a CMake option
>
>
Thank you,I will be looking into ExternalProject_Add and will keep this in
mind while creating my build tree.
Brian
___
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
Re: [CMake] Build only what you need in third party libs
On 22. Dec, 2009, at 16:52 , David Cole wrote:
> On Tue, Dec 22, 2009 at 10:35 AM, Michael Wild wrote:
>
>>
>> On 22. Dec, 2009, at 16:22 , David Cole wrote:
>>
That's exactly my point: if the dependent project is the calling project
(i.e. the one that calls ExternalProject_Add), you have to use
>> error-prone
ADD_LIBRARY( IMPORTED) calls with according invocations of
SET_TARGET_PROPERTIES( PROPERTIES IMPORTED_LOCATION ).
>> In
the case of Boost this is probably very difficult to get right, because
>> from
what I hear, the library names change almost randomly with operating
>> system,
compilation flags and what not. So what ExternalProject.cmake is
>> missing, is
a mechanism of "pulling" the targets of the external project into the
calling project.
>>> So first build boost and everything with a simple "build my
>> prerequisites"
>>> project that builds/installs all your prereqs in a nice, reasonable
>> fashion.
>>>
>>> Then your project can just find/include/import everything as your
>> accustomed
>>> to without any fuss.
>>
>> That is a workable solution for "tech-savvy" users, I'm not so sure the
>> average admin will appreciate it (remembering the heated and quite
>> ridiculous discussions on KDE not providing a configure script anymore...)
>>
>>> There will never be an easy way to pull external projects directly into a
>>> calling project because the external things are not even guaranteed to be
>> on
>>> disk yet at configure time of said calling project.
>>
>>
>> Yeah, kind of a chicken-egg problem...
>>
>
> Exactly. That's why we didn't try to solve that problem. If you have a
> chicken-egg problem to solve, you have to choose starting with a chicken or
> an egg, thereby alienating approximately 50% of your audience, even if you
> have good reasons for your choice.
>
> So: there is one approach that's sort of a hybrid here, that I'll mention
> because it might be useful to consider.
>
> You could have a cmake option in your project that builds your project one
> of two ways: "as usual" or as the final link in a chain of
> ExternalProject_Add calls. I've done this and I know it works, but it's
> proprietary and I cannot point you to the source code. This technique,
> however, does make things hard to think about at times...
>
> Something like this in CMakeLists.txt:
> ==
> option(MYPROJ_UBERBUILD "If ON, build all prereqs first, then build me..."
> ON)
> if(uberbuild)
> include(BuildAllViaExternalProject.cmake)
> else()
> include(BuildJustMe.cmake)
> endif()
>
> And as the last thing inside BuildAllViaExternalProject.cmake:
> ==
> ExternalProject_Add(
> DOWNLOAD_COMMAND ""
> CMAKE_ARGS
>-DMYPROJ_UBERBUILD:BOOL=OFF
> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}
> ...
> )
>
>
> The net effect is that a project can build itself as an ExternalProject with
> the "clever (?)" use of a CMake option
>
>
> HTH,
> David
Very cool idea, but probably not quite easy to maintain as you have to pass all
the cache variables to your own external project... I'll certainly put this
little jewel in my box of useful tricks ;-) But then I'd probably just always
build the main project as an external project and orchestrate the whole thing
from a "meta-project".
Michael
___
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
Re: [CMake] Build only what you need in third party libs
> You are correct: projects that are all intermingled together with > add_subdirectory calls in a parent project *can* interfere with each other, > especially if they do anything with "FORCE" and change variables to > "INTERNAL" to hide them from developers. And then there can simply be > unintended name clashes... > I feared as much. Some sort of project namespace environment variable resolution might help with above issue(see below). Can't say any other tool I ever used did not have the same issue however. CMAKE_EXE_LINKER_FLAGS vs Boost.CMAKE_EXE_LINKER_FLAGS dcmtk.CMAKE_EXE_LINKER_FLAGS > One way to overcome these things, but still build projects from source code > as needed is to use a new feature in CMake 2.8: the ExternalProject module. > There's a cmake function in there called "ExternalProject_Add" that allows > you to build another project as a separate entity so that its CMake settings > are still entirely independent of the settings in all the other projects > you're also building. > > See "cmake --help-module ExternalProject_Add" -- and the test in the CMake > source tree at "CMake/Tests/ExternalProject" -- and the article I wrote > about this in Kitware's "The Source" newsletter: the October 2009 edition: > http://www.kitware.com/products/archive/kitware_quarterly1009.pdf (pp. > 14-17) > > Hopefully, this is helpful... Let me know if you have any questions about > using it. > > :-) > David Cole > > I tried the command C:\Users\bdavis>cmake --help-module ExternalProject_Add cmake version 2.8.0 Argument "ExternalProject_Add" to --help-module is not a CMake module. Must I get latest form source? Or did I do above incorrectly. Also ExternalProject_add is not in : file:///C:/Program%20Files%20%28x86%29/CMake%202.8/doc/cmake-2.8/cmake-commands.html (Windows Install document tree) should it be or is it new? -- Brian J. Davis ___ 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
Re: [CMake] Build only what you need in third party libs
On Tue, Dec 22, 2009 at 10:35 AM, Michael Wild wrote:
>
> On 22. Dec, 2009, at 16:22 , David Cole wrote:
>
> >>
> >> That's exactly my point: if the dependent project is the calling project
> >> (i.e. the one that calls ExternalProject_Add), you have to use
> error-prone
> >> ADD_LIBRARY( IMPORTED) calls with according invocations of
> >> SET_TARGET_PROPERTIES( PROPERTIES IMPORTED_LOCATION ).
> In
> >> the case of Boost this is probably very difficult to get right, because
> from
> >> what I hear, the library names change almost randomly with operating
> system,
> >> compilation flags and what not. So what ExternalProject.cmake is
> missing, is
> >> a mechanism of "pulling" the targets of the external project into the
> >> calling project.
> >>
> >>
> > So first build boost and everything with a simple "build my
> prerequisites"
> > project that builds/installs all your prereqs in a nice, reasonable
> fashion.
> >
> > Then your project can just find/include/import everything as your
> accustomed
> > to without any fuss.
>
> That is a workable solution for "tech-savvy" users, I'm not so sure the
> average admin will appreciate it (remembering the heated and quite
> ridiculous discussions on KDE not providing a configure script anymore...)
>
> > There will never be an easy way to pull external projects directly into a
> > calling project because the external things are not even guaranteed to be
> on
> > disk yet at configure time of said calling project.
>
>
> Yeah, kind of a chicken-egg problem...
>
Exactly. That's why we didn't try to solve that problem. If you have a
chicken-egg problem to solve, you have to choose starting with a chicken or
an egg, thereby alienating approximately 50% of your audience, even if you
have good reasons for your choice.
So: there is one approach that's sort of a hybrid here, that I'll mention
because it might be useful to consider.
You could have a cmake option in your project that builds your project one
of two ways: "as usual" or as the final link in a chain of
ExternalProject_Add calls. I've done this and I know it works, but it's
proprietary and I cannot point you to the source code. This technique,
however, does make things hard to think about at times...
Something like this in CMakeLists.txt:
==
option(MYPROJ_UBERBUILD "If ON, build all prereqs first, then build me..."
ON)
if(uberbuild)
include(BuildAllViaExternalProject.cmake)
else()
include(BuildJustMe.cmake)
endif()
And as the last thing inside BuildAllViaExternalProject.cmake:
==
ExternalProject_Add(
DOWNLOAD_COMMAND ""
CMAKE_ARGS
-DMYPROJ_UBERBUILD:BOOL=OFF
SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}
...
)
The net effect is that a project can build itself as an ExternalProject with
the "clever (?)" use of a CMake option
HTH,
David
___
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
Re: [CMake] Build only what you need in third party libs
On Tue, Dec 22, 2009 at 10:27 AM, Brian Davis wrote: > > > I tried the command > > C:\Users\bdavis>cmake --help-module ExternalProject_Add > cmake version 2.8.0 > Argument "ExternalProject_Add" to --help-module is not a CMake module. > > > Must I get latest form source? Or did I do above incorrectly. Also > ExternalProject_add is not in : > file:///C:/Program%20Files%20%28x86%29/CMake%202.8/doc/cmake-2.8/cmake-commands.html > (Windows Install document tree) should it be or is it new? > Oops. Sorry. Make that: "cmake --help-module ExternalProject" Or online here: http://cmake.org/cmake/help/cmake-2-8-docs.html#module:ExternalProject Thx, David ___ 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
Re: [CMake] Build only what you need in third party libs
Watch out gentoo, and buildroot, here comes cmake ;-) I just tested and it works like a charm, nice job! just as a side note for other users, make certain you don't "quote" your commands. Cheers, Tim On Tue, Dec 22, 2009 at 8:50 AM, David Cole wrote: > On Tue, Dec 22, 2009 at 9:37 AM, Troy D. Straszheim > wrote: >> >> David Cole writes: >> >> > On Tue, Dec 22, 2009 at 7:58 AM, David Wolfe >> > wrote: >> > >> > On 12/22/2009 7:11 AM, David Wolfe wrote: >> > >> > Most of our external >> > dependencies aren't even built using CMake, so 'CMake-ifying' >> > everything >> > under one big über-build hardly seems worth it... >> > >> > >> > On 12/22/2009 6:50 AM, David Cole wrote: >> > >> > One way to overcome these things, but still build projects from >> > source >> > code as needed is to use a new feature in CMake 2.8: the >> > ExternalProject >> > module... >> > >> > >> > Wow. That could be *really* useful---especially the fact that it >> > allows >> > you to download sources from the web, CVS, svn, etc. It might be >> > enough >> > to change my mind about maintaining a separate externals archive. >> > :-) >> > >> > >> > >> > If it's not enough to change your mind.. let me know what you think >> > it's >> > missing. >> > >> >> Here's a use-case: boost-cmake exports buildspace targets to >> $CMAKE_BINARY_DIR/lib/Exports.cmake. So you'd want to download, >> extract, run cmake on the unpacked archive, and only then include() the >> exported targets... Does ExternalProject work this way? > > It does work that way if you set it up that way. > So you would have one ExternalProject_Add call to build and install > boost-cmake... and then a subsequent ExternalProject_Add call to build > something that depends on it. In this dependent project you would use > "DEPENDS boost-cmake-proj" to express this dependency. And pass whatever -D > or prefix information you need to the configure step of this dependent > project so that it knows where the boost-cmake build is. > An external project must configure, build and install all the way before any > of the projects that depend on it even run their first build step. > It's pretty flexible and customizable. If there's a build step that does not > do what you want it to by default, you can replace it with your own custom > step. And you can inject custom steps into the stream of steps that occur by > default, too. > HTH, > David > > ___ > 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 > -- Cheers, Timothy St. Clair ___ 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
Re: [CMake] Build only what you need in third party libs
On 22. Dec, 2009, at 16:22 , David Cole wrote: >> >> That's exactly my point: if the dependent project is the calling project >> (i.e. the one that calls ExternalProject_Add), you have to use error-prone >> ADD_LIBRARY( IMPORTED) calls with according invocations of >> SET_TARGET_PROPERTIES( PROPERTIES IMPORTED_LOCATION ). In >> the case of Boost this is probably very difficult to get right, because from >> what I hear, the library names change almost randomly with operating system, >> compilation flags and what not. So what ExternalProject.cmake is missing, is >> a mechanism of "pulling" the targets of the external project into the >> calling project. >> >> > So first build boost and everything with a simple "build my prerequisites" > project that builds/installs all your prereqs in a nice, reasonable fashion. > > Then your project can just find/include/import everything as your accustomed > to without any fuss. That is a workable solution for "tech-savvy" users, I'm not so sure the average admin will appreciate it (remembering the heated and quite ridiculous discussions on KDE not providing a configure script anymore...) > There will never be an easy way to pull external projects directly into a > calling project because the external things are not even guaranteed to be on > disk yet at configure time of said calling project. Yeah, kind of a chicken-egg problem... Michael ___ 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
Re: [CMake] Build only what you need in third party libs
On Tue, Dec 22, 2009 at 10:12 AM, Michael Wild wrote: > > On 22. Dec, 2009, at 15:50 , David Cole wrote: > > > On Tue, Dec 22, 2009 at 9:37 AM, Troy D. Straszheim >wrote: > > > >> David Cole writes: > >> > >>> On Tue, Dec 22, 2009 at 7:58 AM, David Wolfe > >> wrote: > >>> > >>>On 12/22/2009 7:11 AM, David Wolfe wrote: > >>> > >>> Most of our external > >>>dependencies aren't even built using CMake, so 'CMake-ifying' > >>>everything > >>>under one big über-build hardly seems worth it... > >>> > >>> > >>>On 12/22/2009 6:50 AM, David Cole wrote: > >>> > >>>One way to overcome these things, but still build projects from > >> source > >>>code as needed is to use a new feature in CMake 2.8: the > >>>ExternalProject > >>>module... > >>> > >>> > >>>Wow. That could be *really* useful---especially the fact that it > >> allows > >>>you to download sources from the web, CVS, svn, etc. It might be > >> enough > >>>to change my mind about maintaining a separate externals archive. > :-) > >>> > >>> > >>> > >>> If it's not enough to change your mind.. let me know what you think > >> it's > >>> missing. > >>> > >> > >> Here's a use-case: boost-cmake exports buildspace targets to > >> $CMAKE_BINARY_DIR/lib/Exports.cmake. So you'd want to download, > >> extract, run cmake on the unpacked archive, and only then include() the > >> exported targets... Does ExternalProject work this way? > >> > > > > It does work that way if you set it up that way. > > > > So you would have one ExternalProject_Add call to build and install > > boost-cmake... and then a subsequent ExternalProject_Add call to build > > something that depends on it. In this dependent project you would use > > "DEPENDS boost-cmake-proj" to express this dependency. And pass whatever > -D > > or prefix information you need to the configure step of this dependent > > project so that it knows where the boost-cmake build is. > > > > An external project must configure, build and install all the way before > any > > of the projects that depend on it even run their first build step. > > > > It's pretty flexible and customizable. If there's a build step that does > not > > do what you want it to by default, you can replace it with your own > custom > > step. And you can inject custom steps into the stream of steps that occur > by > > default, too. > > > > HTH, > > David > > > > That's exactly my point: if the dependent project is the calling project > (i.e. the one that calls ExternalProject_Add), you have to use error-prone > ADD_LIBRARY( IMPORTED) calls with according invocations of > SET_TARGET_PROPERTIES( PROPERTIES IMPORTED_LOCATION ). In > the case of Boost this is probably very difficult to get right, because from > what I hear, the library names change almost randomly with operating system, > compilation flags and what not. So what ExternalProject.cmake is missing, is > a mechanism of "pulling" the targets of the external project into the > calling project. > > So first build boost and everything with a simple "build my prerequisites" project that builds/installs all your prereqs in a nice, reasonable fashion. Then your project can just find/include/import everything as your accustomed to without any fuss. There will never be an easy way to pull external projects directly into a calling project because the external things are not even guaranteed to be on disk yet at configure time of said calling project. ___ 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
Re: [CMake] Build only what you need in third party libs
On 22. Dec, 2009, at 15:50 , David Cole wrote: > On Tue, Dec 22, 2009 at 9:37 AM, Troy D. Straszheim > wrote: > >> David Cole writes: >> >>> On Tue, Dec 22, 2009 at 7:58 AM, David Wolfe >> wrote: >>> >>>On 12/22/2009 7:11 AM, David Wolfe wrote: >>> >>> Most of our external >>>dependencies aren't even built using CMake, so 'CMake-ifying' >>>everything >>>under one big über-build hardly seems worth it... >>> >>> >>>On 12/22/2009 6:50 AM, David Cole wrote: >>> >>>One way to overcome these things, but still build projects from >> source >>>code as needed is to use a new feature in CMake 2.8: the >>>ExternalProject >>>module... >>> >>> >>>Wow. That could be *really* useful---especially the fact that it >> allows >>>you to download sources from the web, CVS, svn, etc. It might be >> enough >>>to change my mind about maintaining a separate externals archive. :-) >>> >>> >>> >>> If it's not enough to change your mind.. let me know what you think >> it's >>> missing. >>> >> >> Here's a use-case: boost-cmake exports buildspace targets to >> $CMAKE_BINARY_DIR/lib/Exports.cmake. So you'd want to download, >> extract, run cmake on the unpacked archive, and only then include() the >> exported targets... Does ExternalProject work this way? >> > > It does work that way if you set it up that way. > > So you would have one ExternalProject_Add call to build and install > boost-cmake... and then a subsequent ExternalProject_Add call to build > something that depends on it. In this dependent project you would use > "DEPENDS boost-cmake-proj" to express this dependency. And pass whatever -D > or prefix information you need to the configure step of this dependent > project so that it knows where the boost-cmake build is. > > An external project must configure, build and install all the way before any > of the projects that depend on it even run their first build step. > > It's pretty flexible and customizable. If there's a build step that does not > do what you want it to by default, you can replace it with your own custom > step. And you can inject custom steps into the stream of steps that occur by > default, too. > > HTH, > David > That's exactly my point: if the dependent project is the calling project (i.e. the one that calls ExternalProject_Add), you have to use error-prone ADD_LIBRARY( IMPORTED) calls with according invocations of SET_TARGET_PROPERTIES( PROPERTIES IMPORTED_LOCATION ). In the case of Boost this is probably very difficult to get right, because from what I hear, the library names change almost randomly with operating system, compilation flags and what not. So what ExternalProject.cmake is missing, is a mechanism of "pulling" the targets of the external project into the calling project. Michael ___ 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
Re: [CMake] Build only what you need in third party libs
On Tue, Dec 22, 2009 at 9:37 AM, Troy D. Straszheim wrote: > David Cole writes: > > > On Tue, Dec 22, 2009 at 7:58 AM, David Wolfe > wrote: > > > > On 12/22/2009 7:11 AM, David Wolfe wrote: > > > >Most of our external > > dependencies aren't even built using CMake, so 'CMake-ifying' > > everything > > under one big über-build hardly seems worth it... > > > > > > On 12/22/2009 6:50 AM, David Cole wrote: > > > > One way to overcome these things, but still build projects from > source > > code as needed is to use a new feature in CMake 2.8: the > > ExternalProject > > module... > > > > > > Wow. That could be *really* useful---especially the fact that it > allows > > you to download sources from the web, CVS, svn, etc. It might be > enough > > to change my mind about maintaining a separate externals archive. :-) > > > > > > > > If it's not enough to change your mind.. let me know what you think > it's > > missing. > > > > Here's a use-case: boost-cmake exports buildspace targets to > $CMAKE_BINARY_DIR/lib/Exports.cmake. So you'd want to download, > extract, run cmake on the unpacked archive, and only then include() the > exported targets... Does ExternalProject work this way? > It does work that way if you set it up that way. So you would have one ExternalProject_Add call to build and install boost-cmake... and then a subsequent ExternalProject_Add call to build something that depends on it. In this dependent project you would use "DEPENDS boost-cmake-proj" to express this dependency. And pass whatever -D or prefix information you need to the configure step of this dependent project so that it knows where the boost-cmake build is. An external project must configure, build and install all the way before any of the projects that depend on it even run their first build step. It's pretty flexible and customizable. If there's a build step that does not do what you want it to by default, you can replace it with your own custom step. And you can inject custom steps into the stream of steps that occur by default, too. HTH, David ___ 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
Re: [CMake] Build only what you need in third party libs
David Cole writes: > On Tue, Dec 22, 2009 at 7:58 AM, David Wolfe wrote: > > On 12/22/2009 7:11 AM, David Wolfe wrote: > > Most of our external > dependencies aren't even built using CMake, so 'CMake-ifying' > everything > under one big über-build hardly seems worth it... > > > On 12/22/2009 6:50 AM, David Cole wrote: > > One way to overcome these things, but still build projects from source > code as needed is to use a new feature in CMake 2.8: the > ExternalProject > module... > > > Wow. That could be *really* useful---especially the fact that it allows > you to download sources from the web, CVS, svn, etc. It might be enough > to change my mind about maintaining a separate externals archive. :-) > > > > If it's not enough to change your mind.. let me know what you think it's > missing. > Here's a use-case: boost-cmake exports buildspace targets to $CMAKE_BINARY_DIR/lib/Exports.cmake. So you'd want to download, extract, run cmake on the unpacked archive, and only then include() the exported targets... Does ExternalProject work this way? -t ___ 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
Re: [CMake] Build only what you need in third party libs
Brian Davis writes:
> I am continuing my attempt (latest in the saga) to use cmake to build
> 3rd third party libraries and integrate my code and hopefully build
> only what I need.
> Looking at boost for the CMAKE vars in question I get:
>
> source/cpp/lib/3rdParty/Win32/boost-cmake-1_41_0/CMakeLists.txt:list(APPEND
> CMAKE_MODULE_PATH ${Boost_SOURCE_DIR}/tools/build/CMake)
> source/cpp/lib/3rdParty/Win32/boost-cmake-1_41_0/tools/build/CMake/
> BoostConfig.cmake:set(CMAKE_MODULE_LINKER_FLAGS_DEBUG "" CACHE INTERNAL
> "Unused
> by Boost")
> source/cpp/lib/3rdParty/Win32/boost-cmake-1_41_0/tools/build/CMake/
> BoostConfig.cmake:set(CMAKE_MODULE_LINKER_FLAGS_RELEASE "" CACHE INTERNAL
> "Unused by Boost")
> source/cpp/lib/3rdParty/Win32/boost-cmake-1_41_0/tools/build/CMake/
> BoostConfig.cmake:set(CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL "" CACHE INTERNAL
> "Unused by Boost")
> source/cpp/lib/3rdParty/Win32/boost-cmake-1_41_0/tools/build/CMake/
> BoostConfig.cmake:set(CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO "" CACHE
> INTERNAL "Unused by Boost")
> source/cpp/lib/3rdParty/Win32/vtk-5.4.2/CMake/
> vtkDetermineCompilerFlags.cmake:SET(CMAKE_MODULE_LINKER_FLAGS "$
> {CMAKE_MODULE_LINKER_FLAGS} ${VTK_REQUIRED_MODULE_LINKER_FLAGS}")
>
>
> Which shows CACHE INTERNAL.
>
> Is boost forceably overriding these and keeping user from changing or is there
> a way I can change these.
>
There are a block of these in tools/build/CMake/BoostConfig.cmake, feel
free to delete them. They were added a long ago, before anybody had
thought that one might try to build boost in a subdirectory like this.
Here again boost.cmake is being strange and difficult due to its (imv
misguided) attempts to emulate the strangeness and difficulty of bjam,
which itself originates in the strange and difficult boost dev.
community...
> At this point I also have a very basic question in the use case of CMAKE: Is
> the cmake user suppoed to point cmake-gui separately to each individual
> project, dcmk, boost, vtk, itk, etc or can I do what I am attempting: Create
> one CMakeLists.txt file which references multiple separate project files from
> multiple 3rdParty vendors then point cmake to 1 CMakeLists.txt file (mine) and
> have cmake build all my code and whatever third party libs my apps depend on.
> Currently, if I understand what is happening and I am not saying I do, it
> seems as though each 3rdParty vendor can override global CMakeVariables and
> keep an upper level CMakeList.txt file from setting the variables. This gets
> to my namespace/project resolution question/problem with CMake. Was CMake
> designed for this use case? I have also been having the problem of the
> chicken-and-the-egg with the use of
>
> add_subdirectory( ${THIRD_PARTY_SRC_DIR}/boost-cmake-1_41_0 ./boost )
>
> and
>
> find( boost )
>
> i.e. How can I find boost if I have not build it yet (fresh checkout)
> awesome.
I'm eager to see some enlightened commentary on this as well.
> my current CMakeLists.txt file contains:
>
>
> SET( PLATFORM_DIR platform/3rdParty/Win32 )
> SET( THIRD_PARTY_PACKAGE_DIR source/cpp/lib/3rdParty/Win32 )
> SET( THIRD_PARTY_SRC_DIR lib/3rdParty/Win32/ )
> SET( APP_SRC_DIR source/cpp/app )
>
>
> #Unpack the source - this function I wrote myself to unpack 3rdParty source
> zip
> files into the source tree.
> unpack( ${PLATFORM_DIR}/boost/boost-cmake-1_41_0.zip $
> {THIRD_PARTY_PACKAGE_DIR} )
> #~ unpack( ${PLATFORM_DIR}/ITK/InsightApplications-3.16.0.zip $
> {THIRD_PARTY_PACKAGE_DIR} )
> #~ unpack( ${PLATFORM_DIR}/ITK/InsightToolkit-3.16.0.zip $
> {THIRD_PARTY_PACKAGE_DIR} )
> unpack( ${PLATFORM_DIR}/VTK/vtk-5.4.2.zip ${THIRD_PARTY_PACKAGE_DIR}/vtk-5.4.2
> )
>
> add_subdirectory( ${THIRD_PARTY_SRC_DIR}/dcmtk-3.5.4 ./dcmtk-3.5.4 )
> #~ add_subdirectory( ${THIRD_PARTY_SRC_DIR}/vtk-5.4.2 ./vtk-5.4.2 )
>
> add_subdirectory( ${THIRD_PARTY_SRC_DIR}/boost-cmake-1_41_0 ./boost )
>
> add_subdirectory( app/testing/dicomserver ./dicomserver )
>
>
> SET( Boost_INCLUDE_DIR ${THIRD_PARTY_SRC_DIR}/boost-cmake-1_41_0 CACHE STRING
> "" FORCE )
>
> #add_subdirectory( ${THIRD_PARTY_SRC_DIR}/InsightToolkit-3.16.0 ./
> InsightToolkit-3.16.0 )
> #add_subdirectory( ${THIRD_PARTY_SRC_DIR}/InsightApplications-3.16.0 ./
> InsightApplications-3.16.0 )
>
> #~ find_package( cuda 2.3 )
> #~ find_package( boost )
> find_package( dcmtk )
Wow, look at all that stuff... And on windows too.
> There has been some conflicts adding in certain packages into this file (boost
> and vtk) with dcmtk.
>
> Am I in uncharted shark invested waters on a leaky inflatable raft covered in
> cheese bait, with what I am attempting or has anyone tried what I am trying to
> do. Is this normal or just some form of crazy?
>
Sharks like cheese? Nevermind. What you're trying to do might just
start working at any minute. Hard to say. I doubt it has been done
before on the scale you're doing it, but for simple cases it works
really nicely. When you combine it with git submodules, yo
Re: [CMake] Build only what you need in third party libs
On 22. Dec, 2009, at 14:13 , David Cole wrote: > On Tue, Dec 22, 2009 at 7:58 AM, David Wolfe wrote: > >> On 12/22/2009 7:11 AM, David Wolfe wrote: >> >>> Most of our external >>> dependencies aren't even built using CMake, so 'CMake-ifying' everything >>> under one big über-build hardly seems worth it... >>> >> >> On 12/22/2009 6:50 AM, David Cole wrote: >> >>> One way to overcome these things, but still build projects from source >>> code as needed is to use a new feature in CMake 2.8: the ExternalProject >>> module... >>> >> >> Wow. That could be *really* useful---especially the fact that it allows >> you to download sources from the web, CVS, svn, etc. It might be enough >> to change my mind about maintaining a separate externals archive. :-) > > > > If it's not enough to change your mind.. let me know what you think it's > missing. > > :-) >From my experience, what is missing are some serious examples, showing how to >use this new, excellent feature. And, as I mentioned before, I'm missing MD5 >checking and simplified patching (relying on an external patch command just >does not work reliably). I would also like it if external targets could be "pulled" into the caller project (instead of manually writing tedious and error-prone code for IMPORTED targets). Also, these libraries, if STATIC, should not show up in the LINK_INTERFACE_LIBRARIES when dependent SHARED libraries are exported, because a) their path refers to the build tree, b) they cannot be installed using INSTALL(TARGETS ...) and c) they are not required anyways. Not sure how to do this if the dependent library is STATIC. One could install the external library using INSTALL(FILES ...), but problem a) will need to be managed manually which is again error prone and tedious. I solved a) by writing a custom TARGET_LINK_LIBRARIES wrapper which checks whether a library is IMPORTED and is located in the build tree, adjusts such paths to the install location (possibly using a custom target property) and explicitly setting LINK_INTERFACE_LIBRARIES. Generally, ExternalProject so far doesn't play very nicely with install(EXPORT ...) and EXPORT(...) for me. Michael ___ 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
Re: [CMake] Build only what you need in third party libs
On Tue, Dec 22, 2009 at 7:58 AM, David Wolfe wrote: > On 12/22/2009 7:11 AM, David Wolfe wrote: > >>Most of our external >> dependencies aren't even built using CMake, so 'CMake-ifying' everything >> under one big über-build hardly seems worth it... >> > > On 12/22/2009 6:50 AM, David Cole wrote: > >> One way to overcome these things, but still build projects from source >> code as needed is to use a new feature in CMake 2.8: the ExternalProject >> module... >> > > Wow. That could be *really* useful---especially the fact that it allows > you to download sources from the web, CVS, svn, etc. It might be enough > to change my mind about maintaining a separate externals archive. :-) If it's not enough to change your mind.. let me know what you think it's missing. :-) ___ 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
Re: [CMake] Build only what you need in third party libs
On 12/22/2009 7:11 AM, David Wolfe wrote: Most of our external dependencies aren't even built using CMake, so 'CMake-ifying' everything under one big über-build hardly seems worth it... On 12/22/2009 6:50 AM, David Cole wrote: One way to overcome these things, but still build projects from source code as needed is to use a new feature in CMake 2.8: the ExternalProject module... Wow. That could be *really* useful---especially the fact that it allows you to download sources from the web, CVS, svn, etc. It might be enough to change my mind about maintaining a separate externals archive. :-) ___ 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
Re: [CMake] Build only what you need in third party libs
Am I in uncharted shark invested waters on a leaky inflatable raft
covered in cheese bait, with what I am attempting... ?
Maybe a bit. CMake isn't really intended to be used this way, AFAIK.
CMakeLists.txt files from completely different projects aren't likely to
play nice together. A CMakeLists.txt file from one project could stomp
on global settings used by another, or define a cache variable with the
same name but a totally different meaning.
The way I've typically approached this is to use a python (or shell)
script to run cmake on each dependency and install it to a common
staging area for third party binaries/headers. In pseudo-code,
something like this:
- for each depdir in 3rparty_deps:
mkdir -p depdir/build
cd depdir/build
cmake -DCMAKE_INSTALL_PREFIX=${3RDPARTY_INSTALL_DIR} ..
make -j8 install
(Your post mentioned MSVC? In that case, you'd substitute something like
'devenv.exe ${depdir}.sln /project INSTALL' for the make command above.
You might need to use 'vcexpress.exe instead of devenv.exe.)
Then I make sure that my own project can find those binaries and
headers, usually by specifying something like:
cmake -DCMAKE_PREFIX_PATH=${3RDPARTY_INSTALL_DIR}
Incidentally, if other people are working on the project, I usually tar
up the headers/binaries in ${3RDPARTY_INSTALL_DIR} and encourage
everyone else to just download them directly so they can skip the
bootstrapping step. It's not really cost-effective for every developer
to do this, and there's risk that they'll do it slightly differently and
wind up with binaries that aren't built the same.
This has worked really well for me, but ymmv and all that. I know a
lot of developers feel compelled to merge their project's build with the
third party dependency builds. There's probably a good reason for this,
but it seems unnecessary for our situation. Most of our external
dependencies aren't even built using CMake, so 'CMake-ifying' everything
under one big über-build hardly seems worth it...
___
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
Re: [CMake] Build only what you need in third party libs
On Tue, Dec 22, 2009 at 12:06 AM, Brian Davis wrote: > > I am continuing my attempt (latest in the saga) to use cmake to build 3rd > third party libraries and integrate my code and hopefully build only what I > need. > > > There has been some conflicts adding in certain packages into this file > (boost and vtk) with dcmtk. > Am I in uncharted shark invested waters on a leaky inflatable raft covered > in cheese bait, with what I am attempting or has anyone tried what I am > trying to do. Is this normal or just some form of crazy? > > My investor friends would be pleased. They love sharks! I cannot say for sure if you are coated with any yummy dairy products (after all, this is just email) but, if you are using CMake, then you are most definitely in a sound boat that will float for many years to come. I do understand things can be overwhelming to start with, especially if you are trying to build more than a few things... Rest assured, though, this particular form of crazy is entirely normal. You are correct: projects that are all intermingled together with add_subdirectory calls in a parent project *can* interfere with each other, especially if they do anything with "FORCE" and change variables to "INTERNAL" to hide them from developers. And then there can simply be unintended name clashes... One way to overcome these things, but still build projects from source code as needed is to use a new feature in CMake 2.8: the ExternalProject module. There's a cmake function in there called "ExternalProject_Add" that allows you to build another project as a separate entity so that its CMake settings are still entirely independent of the settings in all the other projects you're also building. See "cmake --help-module ExternalProject_Add" -- and the test in the CMake source tree at "CMake/Tests/ExternalProject" -- and the article I wrote about this in Kitware's "The Source" newsletter: the October 2009 edition: http://www.kitware.com/products/archive/kitware_quarterly1009.pdf (pp. 14-17) Hopefully, this is helpful... Let me know if you have any questions about using it. :-) David Cole ___ 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
Re: [CMake] Build only what you need in third party libs
Hi Brian, all
While I have no experience in building boost and dcmtk at all, I have been
writing a cmake based build framework for my own projects for quite some
time now ( since cmake 2.2), because I was always using cmake in the same
way, and I eventually needed to build different (little) projects with only
one cmakelists.txt, use a bunch of convenience libraries, autodetect
dependencies of dependencies variables, and so on... In short, things that
cmake doesnt do easily right out of the box.
I had problems with variables names clashes between different subprojects,
and I ended up with prefixing my variables for each of my projects ( not the
compilers one though, as far as I remember... ). Athough now cmake as
evolved, ( macro and function have different variable scope), I still use my
build framework, and improve it, for new projects since it make things much
easier for me. That is especially true when different packages that you need
use different naming conventions and other build related specificities...
So... to answer your question about building multiple 3d part libraries when
you need them and that from only one cmakelist.txt refering its
dependencies, I would say cmake doesnt seems to be designed for that in the
first place, however it is doable, as long as you keep the compilation and
the linkage two separate things ( dependencies dont work in the same way and
we tend to shortcut that part too often ). Not really easy to do in a
portable way though...
Sorry for the bad coding standards and lack of comments, but you can always
have a look at https://gna.org/projects/wkcmake/ and check on the few tests
to find out how I managed to do that, even if it still imperfect, and there
is still almost no documentation... Feel free to ask me anything you want to
know about it. Working alone on such a potentially big project, I had to
stop to the strict list of my requirements to go on actual C++ coding, and
therefore it works better on linux than windows right now...
Anyway I hope this helps.
--
AlexV
2009/12/22 Brian Davis
>
> I am continuing my attempt (latest in the saga) to use cmake to build 3rd
> third party libraries and integrate my code and hopefully build only what I
> need.
>
> The two libraries I am building currently are dcmtk (DICOM library) and
> boost.
>
> I am trying to use cmake to create a project which includes dcmtk and
> boost (and other 3rdParty libs) and projects I am creating
>
> I have a CMakeLists.txt file which has the following line removed
>
> #add_subdirectory( ${THIRD_PARTY_SRC_DIR}/boost-cmake-1_41_0 ./boost )
>
> When I use this I see in my CMakeCache.txt (and ultimaetly MSVS project
> files) the following (using grep):
>
>
> build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS:STRING=/machine:x64
> build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING=/debug
> /INCREMENTAL:YES
>
> build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING=/INCREMENTAL:NO
>
> build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING=/INCREMENTAL:NO
> build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING=/debug
> /INCREMENTAL:YES
> build/dvip4-Win64/CMakeCache.txt://ADVANCED property for variable:
> CMAKE_MODULE_LINKER_FLAGS
>
> build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS-ADVANCED:INTERNAL=1
> build/dvip4-Win64/CMakeCache.txt://ADVANCED property for variable:
> CMAKE_MODULE_LINKER_FLAGS_DEBUG
>
> build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
> build/dvip4-Win64/CMakeCache.txt://ADVANCED property for variable:
> CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL
>
> build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
> build/dvip4-Win64/CMakeCache.txt://ADVANCED property for variable:
> CMAKE_MODULE_LINKER_FLAGS_RELEASE
>
> build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1
> build/dvip4-Win64/CMakeCache.txt://ADVANCED property for variable:
> CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO
>
> build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
>
> When I add the line
>
> add_subdirectory( ${THIRD_PARTY_SRC_DIR}/boost-cmake-1_41_0 ./boost )
>
> I get the following (using grep):
>
> build/test-Win64/CMakeCache.txt://ADVANCED property for variable:
> CMAKE_MODULE_LINKER_FLAGS
>
> build/test-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS-ADVANCED:INTERNAL=1
>
> build/test-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS:INTERNAL=/machine:x64
> build/test-Win64/CMakeCache.txt://ADVANCED property for variable:
> CMAKE_MODULE_LINKER_FLAGS_DEBUG
>
> build/test-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
> build/test-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_DEBUG:INTERNAL=
> build/test-Win64/CMakeCache.txt://ADVANCED property for variable:
> CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL
>
> build/test-Win64/CMakeCache.txt:CMAKE_MODUL
Re: [CMake] Build only what you need in third party libs
I am continuing my attempt (latest in the saga) to use cmake to build 3rd
third party libraries and integrate my code and hopefully build only what I
need.
The two libraries I am building currently are dcmtk (DICOM library) and
boost.
I am trying to use cmake to create a project which includes dcmtk and boost
(and other 3rdParty libs) and projects I am creating
I have a CMakeLists.txt file which has the following line removed
#add_subdirectory( ${THIRD_PARTY_SRC_DIR}/boost-cmake-1_41_0 ./boost )
When I use this I see in my CMakeCache.txt (and ultimaetly MSVS project
files) the following (using grep):
build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS:STRING=/machine:x64
build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING=/debug
/INCREMENTAL:YES
build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING=/INCREMENTAL:NO
build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING=/INCREMENTAL:NO
build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING=/debug
/INCREMENTAL:YES
build/dvip4-Win64/CMakeCache.txt://ADVANCED property for variable:
CMAKE_MODULE_LINKER_FLAGS
build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS-ADVANCED:INTERNAL=1
build/dvip4-Win64/CMakeCache.txt://ADVANCED property for variable:
CMAKE_MODULE_LINKER_FLAGS_DEBUG
build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
build/dvip4-Win64/CMakeCache.txt://ADVANCED property for variable:
CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL
build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
build/dvip4-Win64/CMakeCache.txt://ADVANCED property for variable:
CMAKE_MODULE_LINKER_FLAGS_RELEASE
build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1
build/dvip4-Win64/CMakeCache.txt://ADVANCED property for variable:
CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO
build/dvip4-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
When I add the line
add_subdirectory( ${THIRD_PARTY_SRC_DIR}/boost-cmake-1_41_0 ./boost )
I get the following (using grep):
build/test-Win64/CMakeCache.txt://ADVANCED property for variable:
CMAKE_MODULE_LINKER_FLAGS
build/test-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS-ADVANCED:INTERNAL=1
build/test-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS:INTERNAL=/machine:x64
build/test-Win64/CMakeCache.txt://ADVANCED property for variable:
CMAKE_MODULE_LINKER_FLAGS_DEBUG
build/test-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1
build/test-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_DEBUG:INTERNAL=
build/test-Win64/CMakeCache.txt://ADVANCED property for variable:
CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL
build/test-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1
build/test-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:INTERNAL=
build/test-Win64/CMakeCache.txt://ADVANCED property for variable:
CMAKE_MODULE_LINKER_FLAGS_RELEASE
build/test-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1
build/test-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_RELEASE:INTERNAL=
build/test-Win64/CMakeCache.txt://ADVANCED property for variable:
CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO
build/test-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1
build/test-Win64/CMakeCache.txt:CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:INTERNAL=
Notice the change from CMAKE_MODULE_LINKER_FLAGS:STRING to
CMAKE_MODULE_LINKER_FLAGS:INTERNAL. When this happens it appears as though
any calls I have in my CMakeLists.txt file containing:
SET( CMAKE_EXE_LINKER_FLAGS /machine:x64 CACHE STRING "" FORCE )
SET( CMAKE_MODULE_LINKER_FLAGS /machine:x64 CACHE STRING "" FORCE )
SET( CMAKE_SHARED_LINKER_FLAGS /machine:x64 CACHE STRING "" FORCE )
Have no effect.
Looking at boost for the CMAKE vars in question I get:
source/cpp/lib/3rdParty/Win32/boost-cmake-1_41_0/CMakeLists.txt:list(APPEND
CMAKE_MODULE_PATH ${Boost_SOURCE_DIR}/tools/build/CMake)
source/cpp/lib/3rdParty/Win32/boost-cmake-1_41_0/tools/build/CMake/BoostConfig.cmake:set(CMAKE_MODULE_LINKER_FLAGS_DEBUG
"" CACHE INTERNAL "Unused by Boost")
source/cpp/lib/3rdParty/Win32/boost-cmake-1_41_0/tools/build/CMake/BoostConfig.cmake:set(CMAKE_MODULE_LINKER_FLAGS_RELEASE
"" CACHE INTERNAL "Unused by Boost")
source/cpp/lib/3rdParty/Win32/boost-cmake-1_41_0/tools/build/CMake/BoostConfig.cmake:set(CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL
"" CACHE INTERNAL "Unused by Boost")
source/cpp/lib/3rdParty/Win32/boost-cmake-1_41_0/tools/build/CMake/BoostConfig.cmake:set(CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO
"" CACHE INTERNAL "Unused by Boost")
source/cpp/lib/3rdParty/Win32/vtk-5.4.2/CMake/vtkDetermineCompilerFlags.cmake:SET(CMAKE_MODULE_LINKER_FLAGS
"${CMAKE_MODULE_LINKER_FLAGS} ${VTK_REQUIRED_MODULE_LINKER_FLAGS}")
Which shows CACHE INTERNAL.
Is boost forceably overriding these and keeping user from changing or is
th
Re: [CMake] Build only what you need in third party libs
On Wednesday 16 December 2009, Brian Davis wrote: > Sorry for the late reply... it's finals week (school). > > See below > > 2009/12/9 Alexander Neundorf > > > On Saturday 05 December 2009, Brian Davis wrote: > > > I have used boost jam before and there was a mechanism to build only > > > what you need by specifying dependencies within the boost libraries. > > > bjam would > > > then run off calculate deps and build only what I needed. In CMake is > > > there > > > such a feature to specify a third party library and specify only the > > > targets you need to build as dependencies of my build target? > > > i.e. can I use > > > > > > add_subdirectory( lib/3rdParty/Win32/boost-cmake-1_41_0 ./boost ) > > > > > > then create a target that only uses say boost_filesystem and only have > > > that built? Or do I need to build the world to get a handful of needed > > > dll's that are actually used in my project? > > > > Maybe I'm missing the point, but let's say you have library A, B, C and D > > (where B depends on A), and an executable foo, which links against B and > > D. If you then just build the target "foo", the targets A, B and D will > > be built > > automatically (and not C, since foo does not depend on C). > > > > Is this what you mean ? > > > > Alex > > Yes this is it exactly. The problem I have is how to specify these > libraries in third party packages. With boost there is BUILD_PROJECTS > which is boost specific and seems kinda clunky. i.e. I would like to set > BUILD_PROJECTS=NONE and do as you suggest above. Problem comes how do I So you want to build just a part of boost, right ? > specify this (or is it possible) in cmake. I also made refrence to a > namespace issue above which no one has answered. If I make an uber project > of multiple 3rd party libs then is'nt there a chance that (perhaps a bad > example) that the third party lib will use the variable BUILD_PROJECTS as > well. If so what happens in cmake? Each time I specify a new dependency > then I have to run cmake again to build the MS VS project so I can compile. You could add an add_custom_target(foo) and then use add_dependencies(foo lib1 lib2), and then building foo will just build the libs it depends on. But maybe this is what BUILD_PROJECTS does ? Alex ___ 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
Re: [CMake] Build only what you need in third party libs
On Saturday 05 December 2009, Brian Davis wrote: > I have used boost jam before and there was a mechanism to build only what > you need by specifying dependencies within the boost libraries. bjam would > then run off calculate deps and build only what I needed. In CMake is there > such a feature to specify a third party library and specify only the > targets you need to build as dependencies of my build target? > > i.e. can I use > > add_subdirectory( lib/3rdParty/Win32/boost-cmake-1_41_0 ./boost ) > > then create a target that only uses say boost_filesystem and only have that > built? Or do I need to build the world to get a handful of needed dll's > that are actually used in my project? Maybe I'm missing the point, but let's say you have library A, B, C and D (where B depends on A), and an executable foo, which links against B and D. If you then just build the target "foo", the targets A, B and D will be built automatically (and not C, since foo does not depend on C). Is this what you mean ? Alex ___ 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
Re: [CMake] Build only what you need in third party libs
See below
On Mon, Dec 7, 2009 at 1:26 PM, troy d. straszheim wrote:
> Michael Jackson wrote:
>
>>
>>
>> On Dec 7, 2009, at 1:28 PM, troy d. straszheim wrote:
>>
>> Michael Jackson wrote:
>>>
So you are wanting to include the Boost sources in your project and you
just want to build a specific subset of Boost to use with your project?
>>>
>>> Here's what I came up with:
>>>
>>>
>>> http://sodium.resophonic.com/boost-cmake/current-docs/exported_targets.html#with-boost-source-in-a-subdirectory-of-your-source
>>>
>>> the EXCLUDE_FROM_ALL option to add_subdirectory makes things remarkably
>>> easy... nice feature.
>>>
>>> -t
>>>
>>
Yes this appears to be the closest thing to what I would like to do.
>
>>
>> Nice,
>> Couple of comments though:
>> "Setting BUILD_PROJECTS, etc is unnecessary, but if all the extra boost
>> targets bother you you can set it at the commandline as usual:"
>>
>> Why can't I set BUILD_PROJECTS in my own CMakeLists.txt file? Wouldn't
>> this get rid of the need to pass this on the command line? Also what about
>> those running CMake-GUI? They don't have a command line to work from?
>>
>
> Yup, you can, it needs to be CACHE STRING FORCE.
>
>
I am already taking advantage of CACHE STRING FORCE for multiple parameters
to provide "checkout and build" automation with out having to specify these
variables each time. I only wish I could do this for the text box "Where to
build the Binaries" i.e. the ability to fill this in with a default as I
build out of source, but within the checkout directory structure (
rootofcheckout/source and rootofcheckout/build). This way it would be a 3
step to development for developers 1) checkout tree and 2) point cmake to
CMakeLists.txt and 3) press go.
>
> By using the name of the target (boost_filesystem-mt-shared in your
>> example), will CMake automatically "do the right thing" with respect to
>> Debug and release libraries? Will building my project as a Debug pick up the
>> Debug Boost libraries?
>>
>
> No, boost-cmake doesn't play nice with this kind of thing. In the
> beginning we were attempting to do things the way bjam does them, compiling
> all variants with one command. In retrospect I think this was a really bad
> idea. Now things clash, and it would be major surgery to fix... major
> surgery that I may yet do, but realize that it would break a growing amount
> of code that depends on the way boost-cmake now does things. :(
>
> You could check CMAKE_BUILD_TYPE and tweak the name that you're linking
> against:
>
> if (CMAKE_BUILD_TYPE STREQUAL Debug)
> set(DBG_OR_RELEASE "-debug")
> endif()
>
> target_link_libraries(mything boost_filesystem-mt-shared${DBG_OR_RELEASE})
>
>
The do the right thing feature of bjam was quite nice. This is what I was
looking for in CMake as well. It sounds from this discussion that it is a
boost usage of CMake issue not a CMake issue correct or no? Not sure this
is a "solution".
> I see this as having some issues? I now have to detect when someone wants
>> a "Debug" build then set the "BOOST_ENABLE_DEBUG=ON" before calling the
>> add_subdirectory(boost-src).
>>
>
> If you just let boost.cmake configure all the targets, use EXCLUDE_FROM_ALL
> and tweak the name you link to above, only what you need gets built, and
> your CMAKE_BUILD_TYPE works as you expect it to. The same name-tweaking
> above will work if you use exported targets instead of
> boost-src-in-subdirectory.
>
>
ouch... ok will keep this in mind.
> I say all this without having tried any of this but it _is_ intriguing me
>> currently due to all the problems trying to get Boost built OS X and Windows
>> without memory leaks, compile errors and, ya know, basic stuff like that. If
>> I can have my own patched version of boost in my project this may save some
>> serious head aches in the future.
>>
>
>
> And on the boost-cmake list we should talk about what those patches would
> be. You're not the only one doing this, and we have the capacity to do
> point releases of boost asynchronously from upstream.
>
> -t
>
>
>
>
>
> ___
> 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
>
--
Brian J. Davis
___
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
Re: [CMake] Build only what you need in third party libs
Michael Jackson wrote:
On Dec 7, 2009, at 1:28 PM, troy d. straszheim wrote:
Michael Jackson wrote:
So you are wanting to include the Boost sources in your project and
you just want to build a specific subset of Boost to use with your
project?
Here's what I came up with:
http://sodium.resophonic.com/boost-cmake/current-docs/exported_targets.html#with-boost-source-in-a-subdirectory-of-your-source
the EXCLUDE_FROM_ALL option to add_subdirectory makes things
remarkably easy... nice feature.
-t
Nice,
Couple of comments though:
"Setting BUILD_PROJECTS, etc is unnecessary, but if all the extra boost
targets bother you you can set it at the commandline as usual:"
Why can't I set BUILD_PROJECTS in my own CMakeLists.txt file? Wouldn't
this get rid of the need to pass this on the command line? Also what
about those running CMake-GUI? They don't have a command line to work from?
Yup, you can, it needs to be CACHE STRING FORCE.
By using the name of the target (boost_filesystem-mt-shared in your
example), will CMake automatically "do the right thing" with respect to
Debug and release libraries? Will building my project as a Debug pick up
the Debug Boost libraries?
No, boost-cmake doesn't play nice with this kind of thing. In the
beginning we were attempting to do things the way bjam does them,
compiling all variants with one command. In retrospect I think this was
a really bad idea. Now things clash, and it would be major surgery to
fix... major surgery that I may yet do, but realize that it would break
a growing amount of code that depends on the way boost-cmake now does
things. :(
You could check CMAKE_BUILD_TYPE and tweak the name that you're linking
against:
if (CMAKE_BUILD_TYPE STREQUAL Debug)
set(DBG_OR_RELEASE "-debug")
endif()
target_link_libraries(mything boost_filesystem-mt-shared${DBG_OR_RELEASE})
I see this as having some issues? I now have to detect when someone
wants a "Debug" build then set the "BOOST_ENABLE_DEBUG=ON" before
calling the add_subdirectory(boost-src).
If you just let boost.cmake configure all the targets, use
EXCLUDE_FROM_ALL and tweak the name you link to above, only what you
need gets built, and your CMAKE_BUILD_TYPE works as you expect it to.
The same name-tweaking above will work if you use exported targets
instead of boost-src-in-subdirectory.
I say all this without having tried any of this but it _is_ intriguing
me currently due to all the problems trying to get Boost built OS X and
Windows without memory leaks, compile errors and, ya know, basic stuff
like that. If I can have my own patched version of boost in my project
this may save some serious head aches in the future.
And on the boost-cmake list we should talk about what those patches
would be. You're not the only one doing this, and we have the capacity
to do point releases of boost asynchronously from upstream.
-t
___
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
Re: [CMake] Build only what you need in third party libs
On Dec 7, 2009, at 1:28 PM, troy d. straszheim wrote: Michael Jackson wrote: So you are wanting to include the Boost sources in your project and you just want to build a specific subset of Boost to use with your project? Here's what I came up with: http://sodium.resophonic.com/boost-cmake/current-docs/exported_targets.html#with-boost-source-in-a-subdirectory-of-your-source the EXCLUDE_FROM_ALL option to add_subdirectory makes things remarkably easy... nice feature. -t Nice, Couple of comments though: "Setting BUILD_PROJECTS, etc is unnecessary, but if all the extra boost targets bother you you can set it at the commandline as usual:" Why can't I set BUILD_PROJECTS in my own CMakeLists.txt file? Wouldn't this get rid of the need to pass this on the command line? Also what about those running CMake-GUI? They don't have a command line to work from? By using the name of the target (boost_filesystem-mt-shared in your example), will CMake automatically "do the right thing" with respect to Debug and release libraries? Will building my project as a Debug pick up the Debug Boost libraries? I see this as having some issues? I now have to detect when someone wants a "Debug" build then set the "BOOST_ENABLE_DEBUG=ON" before calling the add_subdirectory(boost-src). I say all this without having tried any of this but it _is_ intriguing me currently due to all the problems trying to get Boost built OS X and Windows without memory leaks, compile errors and, ya know, basic stuff like that. If I can have my own patched version of boost in my project this may save some serious head aches in the future. Mike Jackson ___ 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
Re: [CMake] Build only what you need in third party libs
Michael Jackson wrote: So you are wanting to include the Boost sources in your project and you just want to build a specific subset of Boost to use with your project? Here's what I came up with: http://sodium.resophonic.com/boost-cmake/current-docs/exported_targets.html#with-boost-source-in-a-subdirectory-of-your-source the EXCLUDE_FROM_ALL option to add_subdirectory makes things remarkably easy... nice feature. -t ___ 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
Re: [CMake] Build only what you need in third party libs
Please keep on list so that others may benefit/help
So you are wanting to include the Boost sources in your project and
you just want to build a specific subset of Boost to use with your
project?
I guess I might try setting the
# Set what boost libraries will be built
BUILD_PROJECTS=file_system;system
# Configure the Boost CMake distribution to build
add_subdirectory(boost-cmake0 ${PROJECT_BINARY_DIR}/Boost-Cmake0)
# look at for
# more details about the included file. Assuming it is already
generated by the time cmake
# hits this point.
include ( ${PROJECT_BINARY_DIR}/Boost-Cmake0/lib/Exports.cmake )
# Create your executable
add_executable(my_exe ${my_exe_sources} )
# Have your executable link to the boost-file_system library (and
probably the boost-system library)
# Note that the 'boost_file_system' is the actual name of a target
from the Boost-cmake0 sub project.
# See the web page linked above for more details
target_link_libraries ( my_exe boost_file_system)
I have not tried this at all, but this would be my first attempt. The
'target_link_libraries()' command will take care of all the
dependencies for 'my_exe', thus making sure boost-file_system is built
first before building the 'my_exe' executable.
Maybe someone else can comment..
_
Mike Jackson mike.jack...@bluequartz.net
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer Dayton, Ohio
On Dec 7, 2009, at 11:47 AM, Brian Davis wrote:
Yes this looks like an option. Thanks for the lead. It is not
quite what I was expecting.
This seems specific to Boost Libraries. Which brings up 2 questions:
Is there a generic way do this for any third party source tree?
Is there going to be CMAKE variable name resolution clash potential
without namespace resolution within CMake (or is there already this
problem or have I missed something)?
What I would like to do is set (please bear with me as I am a
complete nube to CMake)
BUILD_PROJECTS=none
Then do
add_subdirectory(boost_source_dir)
project( my_exe )
add_executable( my_exe mysource.cpp )
add_library( boost_filesystem SHARED)
#An IMPORTED library target references a library file located
outside the project. No rules are generated to build it. <- Too bad
about this last statement
or
add_dependencies( my_exe boost_filesystem )
Is there any mechanism for project level resolution of third party
source targets such as in bjam boost//boost_filesystem
project
: requirements ../build//boost_filesystem
/boost/system//boost_system
true
;
project boost/filesystem
: source-location ../src
: usage-requirements # pass these requirement to dependents
(i.e. users)
shared:BOOST_FILESYSTEM_DYN_LINK=1
static:BOOST_FILESYSTEM_STATIC_LINK=1
;
And boost_filesystem's use:
project
: requirements
/boost/filesystem//boost_filesystem
msvc:on
;
where some syntax like:
add_subdirectory(boost_source_dir PROJECT boost )
add_dependencies( my_exe boost//boost_filesystem )
or
add_library( boost//boost_filesystem SHARED)
allowing the specification and namespace resolution of the 3rdParty
(boost) library
I know above does not exist as my example question shows, but if it
does in some other form what is it?
Brian
On Sat, Dec 5, 2009 at 3:45 PM, Mike Jackson > wrote:
I _think_ you _might_ be able to set the BUILD_PROJECTS to
"file_system;system" then do the "add_subdirectory()".
Give it a shot and see what happens.
_
Mike Jackson mike.jack...@bluequartz.net
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer Dayton, Ohio
On Sat, Dec 5, 2009 at 4:15 PM, Brian Davis
wrote:
>
> I have used boost jam before and there was a mechanism to build
only what
> you need by specifying dependencies within the boost libraries.
bjam would
> then run off calculate deps and build only what I needed. In CMake
is there
> such a feature to specify a third party library and specify only
the targets
> you need to build as dependencies of my build target?
>
> i.e. can I use
>
> add_subdirectory( lib/3rdParty/Win32/boost-cmake-1_41_0 ./boost )
>
> then create a target that only uses say boost_filesystem and only
have that
> built? Or do I need to build the world to get a handful of needed
dll's that
> are actually used in my project?
>
> --
> Brian J. Davis
>
>
> ___
> 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/unsubs
Re: [CMake] Build only what you need in third party libs
Yes this looks like an option. Thanks for the lead. It is not quite what I was expecting. This seems specific to Boost Libraries. Which brings up 2 questions: Is there a generic way do this for any third party source tree? Is there going to be CMAKE variable name resolution clash potential without namespace resolution within CMake (or is there already this problem or have I missed something)? What I would like to do is set (please bear with me as I am a complete nube to CMake) BUILD_PROJECTS=none Then do add_subdirectory(boost_source_dir) project( my_exe ) add_executable( my_exe mysource.cpp ) add_library( boost_filesystem SHARED) #An IMPORTED library target references a library file located outside the project. No rules are generated to build it. <- Too bad about this last statement or add_dependencies( my_exe boost_filesystem ) Is there any mechanism for project level resolution of third party source targets such as in bjam boost//boost_filesystem project : requirements ../build//boost_filesystem /boost/system//boost_system true ; project boost/filesystem : source-location ../src : usage-requirements # pass these requirement to dependents (i.e. users) shared:BOOST_FILESYSTEM_DYN_LINK=1 static:BOOST_FILESYSTEM_STATIC_LINK=1 ; And boost_filesystem's use: project : requirements /boost/filesystem//boost_filesystem msvc:on ; where some syntax like: add_subdirectory(boost_source_dir PROJECT boost ) add_dependencies( my_exe boost//boost_filesystem ) or add_library( boost//boost_filesystem SHARED) allowing the specification and namespace resolution of the 3rdParty (boost) library I know above does not exist as my example question shows, but if it does in some other form what is it? Brian On Sat, Dec 5, 2009 at 3:45 PM, Mike Jackson > wrote: I _think_ you _might_ be able to set the BUILD_PROJECTS to "file_system;system" then do the "add_subdirectory()". Give it a shot and see what happens. _ Mike Jackson mike.jack...@bluequartz.net BlueQuartz Softwarewww.bluequartz.net Principal Software Engineer Dayton, Ohio On Sat, Dec 5, 2009 at 4:15 PM, Brian Davis wrote: > > I have used boost jam before and there was a mechanism to build only what > you need by specifying dependencies within the boost libraries. bjam would > then run off calculate deps and build only what I needed. In CMake is there > such a feature to specify a third party library and specify only the targets > you need to build as dependencies of my build target? > > i.e. can I use > > add_subdirectory( lib/3rdParty/Win32/boost-cmake-1_41_0 ./boost ) > > then create a target that only uses say boost_filesystem and only have that > built? Or do I need to build the world to get a handful of needed dll's that > are actually used in my project? > > -- > Brian J. Davis > > > ___ > 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 > -- Brian J. Davis ___ 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
Re: [CMake] Build only what you need in third party libs
I _think_ you _might_ be able to set the BUILD_PROJECTS to "file_system;system" then do the "add_subdirectory()". Give it a shot and see what happens. _ Mike Jackson mike.jack...@bluequartz.net BlueQuartz Softwarewww.bluequartz.net Principal Software Engineer Dayton, Ohio On Sat, Dec 5, 2009 at 4:15 PM, Brian Davis wrote: > > I have used boost jam before and there was a mechanism to build only what > you need by specifying dependencies within the boost libraries. bjam would > then run off calculate deps and build only what I needed. In CMake is there > such a feature to specify a third party library and specify only the targets > you need to build as dependencies of my build target? > > i.e. can I use > > add_subdirectory( lib/3rdParty/Win32/boost-cmake-1_41_0 ./boost ) > > then create a target that only uses say boost_filesystem and only have that > built? Or do I need to build the world to get a handful of needed dll's that > are actually used in my project? > > -- > Brian J. Davis > > > ___ > 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 > ___ 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
[CMake] Build only what you need in third party libs
I have used boost jam before and there was a mechanism to build only what you need by specifying dependencies within the boost libraries. bjam would then run off calculate deps and build only what I needed. In CMake is there such a feature to specify a third party library and specify only the targets you need to build as dependencies of my build target? i.e. can I use add_subdirectory( lib/3rdParty/Win32/boost-cmake-1_41_0 ./boost ) then create a target that only uses say boost_filesystem and only have that built? Or do I need to build the world to get a handful of needed dll's that are actually used in my project? -- Brian J. Davis ___ 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
