CPPFLAGS and config.h needed by dependent projects?

[Daniel Pocock]

Hi,

One of my library projects sets quite a few CPPFLAGS and macros in
config.h, most of it is done by configure:

https://svn.resiprocate.org/viewsvn/resiprocate/main/configure.ac?view=markup

We've discovered that in some cases, some other projects using the
headers from reSIProcate need to have some of the same CPPFLAGS and/or
macros in their own config.h, e.g.

https://github.com/catalinusurelu/reConServer/commit/8644e5d581c361fa5eee5f2fbf405cb3cc76f7fa

What is the recommended way to do this?  I don't think it is feasible
for the library project to distribute config.h because things like
PACKAGE_NAME would then be defined twice in some situations.  Nor do I
think it is reasonable for every developer of a dependent package to
have to know which CPPFLAGS were used in building the library.

Is it considered bad practice for the headers from the library project's
public API to be dependent on config.h and/or CPPFLAGS?

Should we be distributing a config script, e.g. bin/xxx-config that can
emit CPPFLAGS?

Regards,

Daniel