[CMake] Build only what you need in third party libs

[Troy D. Straszheim]

Brian Davis <bitminer at gmail.com> 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, you get a
pretty slick system.

One thing you could do is go to exported targets 

  include(/path/to/boost/build/lib/Exports.cmake)

see the docs. This will create a kind of 'firewall' between boost-cmake
and your other stuff, the builds won't be able to clobber one another's
CMAKE_MODULE_LINKER_FLAGS and so forth.  I don't know whether the other
packages you're dealing with will play nice with this or not.

-t