Boost logo

Boost :

Subject: Re: [boost] Cmake
From: P F (pfultz2_at_[hidden])
Date: 2017-06-24 20:31:37

> On Jun 24, 2017, at 3:11 PM, Edward Diener via Boost <boost_at_[hidden]> wrote:
> On 6/24/2017 2:53 PM, P F via Boost wrote:
>>> On Jun 24, 2017, at 1:42 PM, Edward Diener via Boost <boost_at_[hidden]> wrote:
>>> On 6/24/2017 1:05 PM, Peter Dimov via Boost wrote:
>>>> P F wrote:
>>>>> The library for Boost.System is just:
>>>>> bcm_boost_package(system
>>>>> VERSION 1.64
>>>>> src/error_code.cpp
>>>>> 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.
>>> Shouldn't this be generated on the fly ? The sources are all files in the library's 'src' subdirectory and the dependencies come from your own boostdep.
>> What do you mean generated on the fly? This is stored in each repo so that the user can add the libraries as submodules to their project.
> I am saying that this should not have to be maintained manually. That is what I mean by "on the fly". How hard could it be to run some program or Python script which creates such a file for each library automatically ?

I don’t think it would be hard at all. Although, some authors may want to maintain their own cmake, so we don’t want to override the CMakeLists.txt files per-se, and just provide the files such as dependencies.txt and version.hpp, at least from the superproject, since its the only one that knows that information.

For source files, we can just have a script that generates the cmake with the source files that the authors can run locally, or the author can update the list(which is fairly easy) or use file globbing if they want.

Boost list run by bdawes at, gregod at, cpdaniel at, john at