Boost logo

Boost :

Subject: Re: [boost] [CMake] what to do now?
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-04-14 13:48:22

On Thursday, April 14, 2016 at 12:02:14 PM UTC-5, Peter Dimov wrote:
> 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.

Doesn't boost install into the standard ${PREFIX}/include and ${PREFIX}/lib
directories? I don't understand how bpm will remove the headers and the libs
that were installed for a module.

> 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.

cget uses symlinks.

> > 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.

Yes, but having a tool to retrieve these requirements could change the way
libraries are tested. Instead they can be tested against just its
using `cget build --test` instead of needing a full checkout.

> bpm relies on dependency information generated by boostdep,

And that tool could be used to generate the channel needed for cget.

> 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 <boost/foo/bar.hpp> may
> always
> mean the foo library, but we're not there yet and it's not clear if we'll
> ever be.

While it may not be necessary for tooling, that would be nice for developers
to easily know where a header came from.

> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at