[bug#28690] provide a lib output for boost

[Thomas Danckaert]

From: Dave Love <address@hidden>
Subject: Re: [bug#28690] provide a lib output for boost
Date: Fri, 20 Oct 2017 10:20:10 +0100

> > I don't think it's possible to have one output of a package depend 
> > on
> > another, though.  We could just add boost:lib to the inputs for 
> > every
> > package which relies on boost (except for packages which only rely 
> > on
> > header-only parts of boost)?
>
> Sorry, I don't understand; the usual problem seems to be 
> _preventing_
> that, e.g. to cure cycles.  It may not be in the package 
> definition, but
> if I mention "lib" in some file in "out", it will do the job, won't 
> it?

This is enough to retain a store reference to the "lib" output (so 
lib becomes part of the package closure), but I don't think this is 
enough to make the “boost:lib” output available in the build 
environment of a package which only explicitly relies on “boost:out”. 
I mean that a package which needs to link against boost:lib will not 
find it in the build phase, unless boost:lib is explicitly added to 
its inputs (or propagated by boost:out, see my other suggestion).

But I'm largely speculating here, haven't tried any of this out...  
Not sure what the “deficiency” is (provided one of these solutions 
works, maybe they'd both work).  Probably “propagated-inputs”, 
“native-inputs” and normal “inputs” should be explained more 
thoroughly in the manual, perhaps with 1 or 2 examples (As you see, 
I'm not 100% sure how it all fits together, or I'd write it myself.  
Maybe I should just submit a patch for the manual and see what 
comments I get.).

Other than that, having a separate “boost headers” and “boost so's” 
output doesn't sound so bad to me (and isn't it quite common for 
other distributions to have separate packages boost and boost-dev, 
where only boost-dev would include the headers?).

Thomas