Re: [boost] CMake - one more time

On Apr 24, 2016, at 5:56 AM, Peter Dimov 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?