boost-cmake / boost Goto Github PK
View Code? Open in Web Editor NEWCmake-based build of boost
License: Boost Software License 1.0
Cmake-based build of boost
License: Boost Software License 1.0
This is defined for every test, so it should be moved to usage requirements for data_time.
The current version seems to be based on boost 1.66.0. Are there directions for upgrading to 1.67.0?
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.
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.
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.
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 !
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 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()
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
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.
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.
After
cmake .
make
make install
give an error that it cannot find boost/libs/beast/include
.
[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 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.
-- 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:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.