Add_boost script rerunning boost compilation each time

[DominicDirkx]

We have noticed that on many machines, the add_boost script is running through its entirety every time. In particular, you may see the ./b2 .... step every time you make modifications, which can take a long time and is not necessary.

Although this is an issue that should be resolved, this will likely take some time. The 'quick and dirty' fix is to comment out, using the # symbol, line 57, containing:

include(add_boost)

in the top-level CMakeLists.txt file.

[magnific0]

Hi @DominicDirkx, thanks for opening the issue. I have looked into this just now and previously in the past when writing add_boost.cmake, but it is a rather hairy problem.

The FindBoost.cmake module return the variable Boost_FOUND. So in theory we could use

find_package(Boost ${BoostVersion} COMPONENTS {$BoostComponents} REQUIRED)

and put include(add_boost) in a if(Boost_FOUND) clause. This was originally planned, but the problem is that if Boost is present on the system it will fail to build boost locally and use those libraries instead, causing further problems down the line.

By building boost locally and specifying BOOST_INCLUDEDIR and BOOST_LIBRARYDIR
(so called hint variables) we can ensure that the local version of boost is found before the system one.

On a different note, as FindBoost.cmake is already part of CMake since forever, so there is no reason to distribute this module ourselves. It is now present in 7 different locations:

./tudatExampleApplications/libraryExamples/SpiceAndJSON/CMakeModules/FindBoost.cmake
./tudatExampleApplications/libraryExamples/PaGMOEx/CMakeModules/FindBoost.cmake
./tudatExampleApplications/templateApplication/TemplateApplication/CMakeModules/FindBoost.cmake
./tudatExampleApplications/satellitePropagatorExamples/SatellitePropagatorExamples/CMakeModules/FindBoost.cmake
./tudatApplications/myApplication/myApplication/TemplateApplication/CMakeModules/FindBoost.cmake
./tudat/Tudat/External/CMake/FindBoost.cmake

The only possible solution I currently see is: to do a find_package inside add_boost.cmake not only checking if all modules are found but also their paths against the local boost/stage/lib (using string(FIND)). Then unsetting all FindBoost.cmake variables and deciding whether to continue building or not.

[magnific0]

Okay so after writing my previous post, the idea of how to solve this was defined more clearly for me. I have therefore implemented a fix and created a pull request.

The code tries to per component use find_package and checks (1) whether is it found and (2) whether the location matches the local boost library directory.

If checks (1) and (2) pass for all components in BoostComponents list, the remaining portion of the add_boost.cmake function is skipped.

The only downside is that it throws some warnings if it fails checks (1) or (2) which I wasn't able to suppress. A message has been added to inform users that these warnings can be ignored.

Unrelated fix: a message was inserted at the extraction step, warning Windows users that extraction might take very long.

@DominicDirkx can you review the pull request?

[DominicDirkx]

Merged