Paul Fultz II wrote:
How does [bpm] know what files are associated with which library? It seems more difficult to figure that out installing all the libraries together.
It cheats by assuming that library 'foo' is always in $BOOST_ROOT/libs/foo, so it just removes the whole directory. In principle, it could re-download the package and remove only the files it contains, or it could record the files somewhere so it would know what to remove. But for Boost specifically, this doesn't seem worth the bother, because libraries are indeed contained in their libs/ subdirectories.
Although, I don't think its unreasonable for a library to track its own dependencies.
It may be reasonable... but for a Boost library it's not going to be very
reliable. Since Boost library maintainers nearly always work against a full
checkout, libraries can acquire (and sometimes drop) dependencies via a
one-line edit and it's very easy to forget to record this in a
'requirements' file.
bpm relies on dependency information generated by boostdep, but I need to
rework it to scan on its own. The additional problem here is that if you
don't have the full checkout you don't know what module contains which
header. At some point in the future #include