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.