[build2] Reverse Dependency via Defines

[Boris Kolpackov]

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.