Re: [boost] [CMake] what to do now?

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 
dependencies
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: 
> http://lists.boost.org/mailman/listinfo.cgi/boost 
>