[build2] Reverse Dependency via Defines

[Kalle Møller]

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>
wrote:

> 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
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.build2.org/archives/users/attachments/20181204/f54e2f62/attachment.html>