Build BOOST within project.

[magnific0]

This commit will build boost within the project. A new add_boost.cmake file is necessary (see pull request on Tudat main repository).

Currently this has only been tested on Linux. Windows tests will follow (with additional fixes).

I propose to go ahead with merge as the current system is broken with Windows anyway. It is the intention to get this new way of using Boost confirmed with Linux first and then on other systems.

[DominicDirkx]

Hey, I've gone through your code, and it runs smoothly, downloads and compiles boost as needed.

However, it does not use the compiled version of boost, but goes for my system installation instead. To prevent incompatibilities with system installations (which have occured numerous times in the past...), I propose ending the add_boost.cmake file with:

SET(Boost_INCLUDE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/boost/")

This will force the code to use the just compiled version of Boost, regardless of any system installation.

For the next iteration, it would be good to see if we can tweak the add_boost script so that it only compiles those elements of boost that are needed.

If we can get this solution tested on Mac/Windows, I'm all for adding this to the repository. It'll be a nice solution for something that has been causing headaches for years...

[magnific0]

Hi @DominicDirkx I have incorporated your comments and the suggestion for a per-component boost build option. Everything works splendidly on Windows. I don't think the changes has had any effect on our previous success on Linux, can you nonetheless verify this? Thansk!

[magnific0]

@DominicDirkx can you please include the following request in your test branch? This fix is for Windows (and works properly), however it has not been confirmed to not screw up on *nix systems.

https://github.com/magnific0/cspice/pull/1

[magnific0]

I can now confirm that the version of MinGW32 that ships with QtCreator (featuring GCC 4.9.1) works without any of the previous MinGW32 (4.8.1) patches.

[DominicDirkx]

Great, thank for all the hard work in getting this ready. I've checked the compatibility on Ubuntu 14.04, gcc 4.8.4, cmake 3.4.3.

It mostly checks out, I have some small comments on the Tudat and TudatExampleApplications code:

The line:

SET(Boost_INCLUDE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/boost/")

(or something to this effect) has not been added, so the code still doesn't use the self-compiled version of boost.

Also, the CMakeLists for the TemplateApplication is not updated, so it isn't compatible anymore.

[DominicDirkx]

I've also tried compiling Tudat bundle with clang. To get it to use clang, we have to move the

include(${CMAKE_MODULE_PATH}/compiler.cmake)

to be called before the

project( Tudat....

command in each project (see https://cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F)

For instance, by starting the tudat bundle CMakeLists as follows:

cmake_minimum_required( VERSION 2.8.10 ) set(PROJECTROOT "${CMAKE_CURRENT_SOURCE_DIR}/") set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_CURRENT_SOURCE_DIR}/tudat/Tudat/External/CMake/") set(USE_CLANG ON) include(${CMAKE_MODULE_PATH}/compiler.cmake)

and similarly for Tudat and the Applications, clang is recognized and used.

Once compiles with clang 3.4.1 everything runs fine.

[DominicDirkx]

Just as an additional comment to the previous post, we should find some way of allowing the whole bundle to be built at once (in which case the compiler etc. should only be set once) or allowing Tudat and the applications to be built separately.

We could set a variable USE_TUDAT_BUNDLE to true in the top-level CMakeLists, and let Tudat and the applications check whether this variable exists (and is true). If true, nothing needs to be done. If false, it should call its own compiler.cmake/add_boost.cmake files. What do you think?

[DominicDirkx]

To make things a bit more transparent, I'll merge your pull requests and fix the two small issues I found (Boost_INCLUDE_DIR and TemplateApplication) in a next issue that I'll commit shortly.

We can address the clang issues and the issue of (in)dependence between tudat and tudatBundle in a next issue.