Thomas Danckaert writes: >> 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). Sorry, yes. I've fallen for that before, now I think of it. > 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. That's two of us. I've intended to write something for "conversion" from other packaging systems, but definitely don't understand enough yet.