Re: [boost] CMake - one more time

Subject: Re: [boost] CMake - one more time
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-04-24 11:44:30

> On Apr 24, 2016, at 5:56 AM, Peter Dimov <lists_at_[hidden]> wrote:
> 
> Raffi Enficiaud wrote:
>> But as you point out, I believe that tools such as BPM can be augmented with some "intelligent cloning" of submodules for instance, which would avoid that. So then you would have to clone the superproject in a shallow manner, and then compile BPM to clone the subset of libraries you need. This will address the particular use-case you are referring to in the case of Hana, and I believe this is useful for many people as well. The DAG that BPM is maintaining can be updated manually, or in a commit oriented manner by the robot for instance (although I do not like robots being empowered with commit ability).
> 
> My original idea for BPM was for the packages and the dependency file to be prepared by some kind of release script, to replace the monolithic release.

What would be nice if BPM was extensible to support libraries in the incubator. That is the user had some form of channel or PPA that could be added, which would install these unofficial libraries as well.

> 
> But now I think that this is unnecessary; I plan to rework it to download the packages directly from Github, and to scan the dependencies in place, so as to eliminate the need for a bpm-specific packaging.

Wouldn’t it need to download all of boost to do that? Otherwise, how does it know which header belongs to which library?

> The idea is to be able to say
> 
>   bpm -r <commit-or-tag> test filesystem
> 
> and it would go and download filesystem and all its test dependencies from Github and then execute the equivalent of
> 
>   b2 <commit-or-tag>/libs/filesystem/test
> 
> This would be very useful in .travis.yml, except that you'd need to somehow bootstrap bpm first.

And b2 as well, correct?