Re: CMake and Boost

From: Robert Ramey (ramey_at_[hidden])
Date: 2024-06-11 18:36:09

On 6/11/24 1:20 AM, Alexander Grund via Boost wrote:
>  "Modular boost" refers 
> to B2 IIRC so this is orthogonal.

A mistake in my view.  CMake for boost should support "modularization".

> 
>> 2) BOOST_INCLUDE_LIBRARY
>>
>> I would like my CMakeLists.txt file to explicitly list the direct 
>> antecedent libraries (dependencies - bad word usage).  So I'd expect 
>> to see something like
> No, in CMake you specify your direct dependencies with 
> `target_link_libraries`. 

The CMakeLists.txt in each

The top-level Boost build (the CMake machinery
> added by Peter) has logic to add the required subdirectories.
> You only need to list each `Boost::foo` target on a separate line. See 
> e.g.: 
> https://github.com/boostorg/variant2/blob/develop/CMakeLists.txt#L15C1-L20
> 
>> add_(sub?)directory(../filesystem)
>> add_(sub?)directory(../regex)

The CMakeLists.txt in each (sub?)directory would contain the 
"target_link_libraries" if required.  It's possible that some library 
might might be dependent on something besides another library - e.g. a 
test data generator executable.  So using add_subdirectory would be more 
general.

> 
> This can and needs to be done to test whether you can use your library 
> itself with `add_subdirecory` which is an extra test, see e.g. 
> https://github.com/boostorg/variant2/blob/develop/test/cmake_subdir_test/CMakeLists.txt
> 
> 
>> So I could just
>> cd to .../libs/serialization
>> cmake --build
>>
>> and have it build the antecedent if and only if required.
> A bit different:
> - cd to new build folder
> - cmake <boost-root> -DBOOST_INCLUDE_LIBRARY=serialization
> - cmake --build
> 
> BOOST_INCLUDE_LIBRARY is basically the/our CMake way of "b2 --with-foo"

Right. and it's only required because we're presuming that the 
invocation is from boost rather than from within the library directory 
itself.  Again - use this project to support the "modularization" of Boost.

> 
>> 3) CMAKE_INSTALL_INCLUDEDIR
>>
>> I would prefer not to "install" (copy) the include files but just use 
>> the ones from their original locations.
> That variable is only used for installation. Nothing is copied for the 
> build
>>
>> 4) BUILD_TESTING
>>
>> I would prefer to have my library source tree to look like:
>>
>> ... libs/serialization
>> Â  CMakeLists.txt
>> Â Â Â  // includes add_directory for subdirectorys build, test, example, 
>> profile and ...
>> Â Â Â  // includes add_directory for antecedent libraries like 
>> add_directory(../libs/filesystem)
>> Â  include // directory with include files for users of serialization 
>> library
>> Â  build(or src) // source files for library build
>> Â Â Â  CMakeLists.txt // to build library
>> Â  test
>> Â Â Â  CMakeLists.txt
>> Â  example
>> Â Â Â  CMakeLists.txt
>> Â  profile
>> Â Â Â  CMakeLists.txt
>>
>> Maybe the add_directory would be conditioned on a CMAKE variable.
> You can:
> See 
> https://github.com/boostorg/variant2/blob/f9bdafd3ca0f5025012f60a405b559888513a9be/CMakeLists.txt#L33-L37
> Also already done for your root CML
>> So if I invoke
>>
>> CMake --build test_polymorphic_binary_archive
>>
>> It would recursively (re)build everything necessary and nothing not 
>> necessary
> This requires `-DBUILD_TESTING=ON` but otherwise it will work. 

Good> However your targets should be prefixed like
> "boost_serialization_test_polymorphic_binary_archive"

why?
>>
>> If I didn't specify a list of targets, it would recursively (re)build 
>> everything that needs (re)building.
> Yes
>> in particular recursive inclusion of header files and likely some 
>> other stuff.
> Yes this is done
>> I've also experimented with CMake enough to have a feeling that what I 
>> want to do is not possible.  And this is the short version of what I'd 
>> like to do.
> See above: With a bit care it is possible. Take some of Peters libraries 
> as a starting point.
>  From what I can only the CMLt in your test folder is missing. 

A long time ago I put CMake stuff into the directory 
libs/serialization/cmake in order to avoid crossing swords with the 
eventual developers of the Boost CMake implementation - which has turned 
out be peter.  It's worked out OK.  Its not hard to move the stuff in 
that directory into the future test/CMakeLists.txt when it seems 
advantageous.

> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost