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