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
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
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 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
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 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
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
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
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
[CMake] [Q] LINK_INTERFACE_LIBRARIES and the like
Hi all, After reading, re-reading, and re-re-reading the manual, I still don't really get the concept of LINK_INTERFACE_LIBRARIES, IMPORTED_LINK_DEPENDENT_LIBRARIES, and IMPORTED_LINK_INTERFACE_LIBRARIES. Is this mostly Windows-specific, or does it also apply for Linux? Best regards, Marcel Loose. ___ 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 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] [Q] LINK_INTERFACE_LIBRARIES and the like
On 22. Dec, 2009, at 15:52 , Marcel Loose wrote:
> Hi all,
>
> After reading, re-reading, and re-re-reading the manual, I still don't
> really get the concept of LINK_INTERFACE_LIBRARIES,
> IMPORTED_LINK_DEPENDENT_LIBRARIES, and
> IMPORTED_LINK_INTERFACE_LIBRARIES. Is this mostly Windows-specific, or
> does it also apply for Linux?
>
> Best regards,
> Marcel Loose.
>
LINK_INTERFACE_LIBRARIES is a property you can set if you want to override the
set of libraries that appear in the link-interface of one of your own libraries.
IMPORTED_LINK_INTERFACE_LIBRARIES is the same for IMPORTED targets. E.g.
suppose you have this:
add_library(foo ${FOO_SRCS})
target_link_libraries(foo bar)
install(EXPORT ${PROJECT_NAME}Dependencies DESTINATION )
The created /${PROJECT_NAME}Dependencies.cmake file will list "bar"
in the LINK_INTERFACE_LIBRARIES of "foo". This property is essentially a copy
of LINK_INTERFACE_LIBRARIES property of "foo" in the build tree (if it is
defined).
IMPORTED_LINK_DEPENDENT_LIBRARIES is AFAIK similar to
IMPORTED_LINK_INTERFACE_LIBRARIES but refers to dependencies that are
"implementation details".
HTH
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 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
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 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
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
> 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 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
> > 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 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
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
[CMake] Fwd: Build only what you need in third party libs
Thanks guys, I ll have a look at External Project sometimes too, seems it could make my code a bit simpler. For what it s worth, in my custom build framework, to make things simple I assume a few ( very arguable and arbitrary ) things. Among them : - the source and build folder hierarchy is known and always the same, which helps me to automatically detect built things in the right place. - I expect the developer to build his dependencies when needed ( a simple "build just me" choice ), but I ( try to ) provide dependencies detection... For automatic building I would use the "simple shell script" solution, that will build things in the right order. This enables me to generate automatically and consistently the *Config.cmake and the *Export.cmake files which makes the job so much easier :-) In conclusion I d say that when it s possible for you to know how are your source tree and your build tree organized, it becomes easy to manage multiple related projects, as you can automate most of the build steps. -- AlexV 2009/12/22 David Cole > 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 > ___ 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 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
