Re: [boost] CMake - one more time

Subject: Re: [boost] CMake - one more time
From: Peter Dimov (lists_at_[hidden])
Date: 2016-04-24 06:56:50

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.

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. 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. On Windows, one would be able to just download bpm.exe.