boost-cmake / boost Goto Github PK

The project contains a large amount of deprecated names (policy CMP0037), such as windows/basic_handle.

This causes the VS2017 generator to fail with CMake 3.8.1 (also tested with 3.9):

CMake Error at bcm/share/bcm/cmake/BCMFuture.cmake:68 (_add_library):
  The target name "windows/basic_handle" is reserved or not valid for certain
  CMake features, such as generator expressions, and may result in undefined
  behavior.
Call Stack (most recent call first):
  bcm/share/bcm/cmake/BCMTest.cmake:104 (add_library)
  libs/asio/test/CMakeLists.txt:115 (bcm_test)

Setting the policy to the old version explicitly hides the problem for this generator:

cmake_policy(SET CMP0037 OLD)

I'm also not sure why it is an error by default - according to the CMake docs, this policy should be a warning by default, maybe it has something to do with the VS generator, as I see no similar problems on linux with Ninja.

[build@shapdis00001 context]$ make
[ 0%] Built target boost_system
[ 0%] Built target boost_atomic
[ 0%] Built target boost_chrono
[ 0%] Built target boost_container
[ 0%] Built target boost_exception
[100%] Built target boost_regex
[100%] Built target boost_filesystem
[100%] Built target boost_random
[100%] Built target boost_iostreams
[100%] Built target boost_thread
[100%] Built target boost_serialization
[100%] Built target boost_locale
[100%] Built target boost_date_time
[100%] Building ASM object libs/context/CMakeFiles/boost_context.dir/src/asm/make_x86_64_sysv_elf_gas.S.o
/usr1/build/bin/ccache: invalid option -- 'D'
Usage:
ccache [options]
ccache compiler [compiler options]
compiler [compiler options] (via symbolic link)

Options:
-c, --cleanup delete old files and recalculate size counters
(normally not needed as this is done automatically)
-C, --clear clear the cache completely (except configuration)
-F, --max-files=N set maximum number of files in cache to N (use 0 for
no limit)
-M, --max-size=SIZE set maximum size of cache to SIZE (use 0 for no
limit); available suffixes: k, M, G, T (decimal) and
Ki, Mi, Gi, Ti (binary); default suffix: G
-o, --set-config=K=V set configuration key K to value V
-p, --print-config print current configuration options
-s, --show-stats show statistics summary
-z, --zero-stats zero statistics counters

-h, --help            print this help text
-V, --version         print version and copyright information

See also https://ccache.samba.org.
make[2]: *** [libs/context/CMakeFiles/boost_context.dir/src/asm/make_x86_64_sysv_elf_gas.S.o] Error 1
make[1]: *** [libs/context/CMakeFiles/boost_context.dir/all] Error 2
make: *** [all] Error 2

The current version seems to be based on boost 1.66.0. Are there directions for upgrading to 1.67.0?

Logic such as this:

if(boost_throw_exception_FOUND)
file(APPEND "${PROJECT_BINARY_DIR}/boost_mpi-config.cmake" "
find_package(boost_throw_exception)
")

should be using find_dependency (from CMakeFindDependencyMacro). This is equivalent to find_package but is specifically for use in recursive calls inside configuration scripts.

Paul

as you might or might not be aware, I'm taking on the job of getting CMake support in Boost. To this end I've posted draft version of "Requirements and Scope" along with rules for review of submissions that we hope to receive by 1 February 2019. If you haven't seen this yet, please. check the developers list where it's been posted. If you can't find it there, just email me directly. I would very much like to see you participate in this.

Robert Ramey

After

cmake .
make

make install give an error that it cannot find boost/libs/beast/include.

The boost thread library build depends on the existence of the BOOST_THREAD_BUILD_LIB (static) or BOOST_THREAD_BUILD_DLL (dynamic) definitions.

In the normal build, it is defined in its Jamfile.

Without one of these defined, it marks functions defined in cpp files with dllimport on Windows.

The following addition to its CMakeLists solves the problem:

if (BUILD_SHARED_LIBS)
    target_compile_definitions(boost_thread PRIVATE BOOST_THREAD_BUILD_DLL)
else()
    target_compile_definitions(boost_thread PRIVATE BOOST_THREAD_BUILD_LIB)
endif()

When CMake can't find python, the boost::python package is correctly skipped.

However, the parameter library still tries to link with it.

This causes several errors after the configuration phase such as:

CMake Error at bcm/share/bcm/cmake/BCMFuture.cmake:68 (_add_library):
  Target "log-compile-current_function_support" links to target
  "boost::python" but the target was not found.  Perhaps a find_package()
  call is missing for an IMPORTED target, or an ALIAS target is missing?
Call Stack (most recent call first):
  bcm/share/bcm/cmake/BCMTest.cmake:104 (add_library)
  libs/log/test/CMakeLists.txt:62 (bcm_test)

An easy way to reproduce this is, for example, to do a 64 build on a machine with only the 32-bit python libraries present.

Commenting out the line I referenced solved the problem in this case, and I was able to build the project - so I think it should be conditional.

And also, other, optionally built libraries referenced in this way could cause similar issues.

-- Could NOT find MPI_C (missing:  MPI_C_LIBRARIES MPI_C_INCLUDE_PATH)                         
-- Could NOT find MPI_CXX (missing:  MPI_CXX_LIBRARIES MPI_CXX_INCLUDE_PATH)

Currently it seems that missing build dependencies results in a build failure, rather than skipping of optional components. Has this been discussed previously? Strategies could include:

• having a cache variable set to ON|OFF|AUTO and have it fail if not present and set to ON, build if present and set to AUTO, or not build if set to OFF
• always autodetecting and building/not building if available/not available

Scanning dependencies of target boost_stacktrace
[ 93%] Building CXX object libs/stacktrace/CMakeFiles/boost_stacktrace.dir/src/backtrace.cpp.o
In file included from /code/boost/libs/stacktrace/include/boost/stacktrace/detail/frame_unwind.ipp:25:0,
                 from /code/boost/libs/stacktrace/src/backtrace.cpp:10:
/code/boost/libs/stacktrace/include/boost/stacktrace/detail/libbacktrace_impls.hpp:19:10: fatal error: backtrace.h: No such file or directory
 #include <backtrace.h>
          ^~~~~~~~~~~~~
compilation terminated.

This was on Manjaro Linux.

The compilation of the log component fails because a missing header file: simple_event_log.h

This file should be generated with the mc tool, but instead, the CMakeLists adds the mc file to the sources.

In looking at the Boost Build jamfile for tests in preprocessor, tti, and vmd I noticed a number of Boost Build constructs that are left out of the conversion to CMake, but which should have CMake equivalents. I do not know if you are generating the CMakeLIsts.txt files manually for each library or whether you have a script for doing so, but if it is the latter perhaps these conversion facilities from Boost Build to CMake can be added. Or perhaps you can offer some bcm equivalents for some of these things to ease the manual conversion which individual library developers will have to do in generating the correct CMake test scripts from their Boost Build equivalents.

1. Boost Build has the notion of a 'project' rule. The main use for the 'project' rule is to be able to specifying build requirements to each rule in the jamfile. For testing purposed the use of 'project' rule requirements is largely so that the same requirement for each individual test does not have to be repeated again and again. I believe the equivalent to this in CMake is the ability to set build properties for the entire CMakeLists.txt rather than to set target properties. I know the official Daniel Pfeiffer document frowns on setting global properties as opposed to specific target properties, but this is nonsense as far as I am concerned. If you have a group of tests, why should you have to repeat the same build requirement for each and every test repeatedly when you can set the build requirement once for all the tests. In your conversion from Boost Build to CMakeLists.txt you ignored the 'project' rule entirely.

2. Boost Build has the notion of conditional requirements using the property:property syntax. This is the equivalent of testing for some value in CMake with an 'if(something)', and then setting some CMake value based on that test. I noticed that you ignored conditional requirements completely in your converted CMakeLists.txt files for library tests.

3. Boost Build has the ability to specify particular compiler and compiler/version pairs directly using the notation 'compiler_id-optional_version_string'. This is the equivalent of CMake variables CMAKE_CXX_COMPILER_ID and CMAKE_CXX_COMPILER_VERSION, but with different compiler ids and with slightly different version string notations. Often in Boost Build the notation is used with conditional requirements to set a property based on the compiler or compiler/version being used in the compile. This is very useful for test when it is known that some compiler will fail a test unless some compiler option is set correctly.

I have brought up these three issues simply to explain why your CMakeLists.txt files for library tests might fail. You have done a great job with bcm and your work of creating CMake files for Boost using bcm, and should be commended. My major concern is that the more library developers ( like me ), who are not CMake experts like you, have to do manually to use CMake for their libraries instead of Boost Build, the less likely they are to want to do anything. Subsequently their tests using CMake might fail using particular toolsets even when their tests using Boost Build will succeed.

Thanks for your efforts !

This is defined for every test, so it should be moved to usage requirements for data_time.