<div dir="ltr">My problem arises as I'm building a library that uses Boost, and depends on Booot.Config, and therefore implicit depends on the user supplied config (if it is defined). As an exercise I thought I would package just the Boost.Config (as it has no other Boost dependencies), and let my library just depend on that. This is where I got stuck. I saw no good way to package and make the dependencies, and also let the consumer provide the user config.</div> <div class="gmail_quote"><div dir="ltr">On Tue, 4 Dec 2018 at 09:52, Boris Kolpackov <<a href="mailto:boris@codesynthesis.com">boris@codesynthesis.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Kalle Møller <<a href="mailto:build2.org@k-moeller.dk" target="_blank">build2.org@k-moeller.dk</a>> writes: > Have you any thoughts on how reverse dependencies should be handled? > > Here I think about libraries/programs that let you optionally/required to > provide header and maybe even a library. If this library/program is meant to be packaged, then you should avoid such reverse dependencies since a package may be used by multiple consumers. If this is for an "end-product" (i.e., something the you have no intention of packaging/reusing), then something ad hoc should do the trick. For example, you may require that the corresponding macro be defined before including the header or provide a command line option (i.e., -D). Soon we should also have support for custom project configuration (via the config.* variables) at which point it will also be an option. > This for me also ties into how should you handle poptions that a headerfile > set? Im here thinking about cxx.export.poptions, should that get populated > with these defines? No, this won't work and I don't believe this is a correct approach since the same library, in the general case, can be used by multiple consumers. They cannot all be "configuring" the library. </blockquote></div>