Re: [boost] Cmake

Subject: Re: [boost] Cmake
From: P F (pfultz2_at_[hidden])
Date: 2017-06-24 18:05:13

> On Jun 24, 2017, at 12:05 PM, Peter Dimov via Boost <boost_at_[hidden]> wrote:
> 
> P F wrote:
>> https://github.com/pfultz2/boost-cmake-demo/tree/bcm-demo
>> 
>> The library for Boost.System is just:
>> 
>> bcm_boost_package(system
>>  VERSION 1.64
>>  SOURCES
>>    src/error_code.cpp
>>  DEPENDS
>>    assert
>>    config
>>    core
>>    predef
>> )
> 
> This certainly looks cleaner. It needs to distinguish between public and private dependencies but that's easy to fix. And of course there's the question who will maintain the version and the dependency list.

The version and dependency list could be generated by the superproject, like in your example. 

Ideally, the version could be a header in `boost/{module}/version.hpp` with macro such as `BOOST_{module}_VERSION`. The `bcm_boost_package` can parse this header to retrieve the version. In fact, bcm already has support for something like this already:

http://bcm.readthedocs.io/en/latest/src/BCMPackage.html#cmdoption-bcm-boost-package-arg-version-header

Although, we may need a whitelist, or someway to deal with libraries that have their own versioning scheme(like Boost.Hana).

For dependencies, we could generate a dependencies.txt file from the superproject, and have an argument for the file rather than write it directly in the cmake file.

> 
>> And this works for both `add_subdirectory` build and standalone builds.
> 
> Provided that the user has installed BCM, I presume? Because otherwise find_package(BCM) won't work. 

Yes, of course, and considering that building standalone requires quite a bit of dependencies(six just for system) to be installed already, I don’t think one more dependency will be a problem in this scenario.