[build2] Reverse Dependency via Defines
build2.org at k-moeller.dk
Tue Dec 4 09:29:03 UTC 2018
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.
On Tue, 4 Dec 2018 at 09:52, Boris Kolpackov <boris at codesynthesis.com>
> Kalle Møller <build2.org at k-moeller.dk> 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
> 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
> > set? Im here thinking about cxx.export.poptions, should that get
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users