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

[LRN]

Post by Daniel Pocock
One of my library projects sets quite a few CPPFLAGS and macros in
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.
Should we be distributing a config script, e.g. bin/xxx-config that can
emit CPPFLAGS?

Either that, or distribute a .pc file for pkg-config (and appropriate
.m4 for dependent projects to use, if you don't have these already).

- --
O< ascii ribbon - stop html email! - www.asciiribbon.org

[Nate Bargmann]

Post by LRN

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

Either that, or distribute a .pc file for pkg-config (and appropriate
.m4 for dependent projects to use, if you don't have these already).

I'll concur as the Hamlib project only installs the public headers, none
of which depend on config.h, and a hamlib.pc and hamlib.m4 file. I have
yet to receive a request from any of our consumers to know what *FLAGS
were used. To be clear, the only binaries the project provide are for
Windows and the free OS distributions build their own binaries.

As I understand it, config.h is a snapshot of the build system at
configure time. After a few upgrades of the build system it may well be
out of date and require a configure run to update it. We've tried to
adhere to a policy that the public API should not depend on a localized
configuration.

- Nate

[Mike Frysinger]

Post by Nate Bargmann

Post by LRN

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

Either that, or distribute a .pc file for pkg-config (and appropriate
.m4 for dependent projects to use, if you don't have these already).

I'll concur as the Hamlib project only installs the public headers, none
of which depend on config.h, and a hamlib.pc and hamlib.m4 file. I have
yet to receive a request from any of our consumers to know what *FLAGS
were used. To be clear, the only binaries the project provide are for
Windows and the free OS distributions build their own binaries.
As I understand it, config.h is a snapshot of the build system at
configure time. After a few upgrades of the build system it may well be
out of date and require a configure run to update it. We've tried to
adhere to a policy that the public API should not depend on a localized
configuration.

at the risk of just adding noise, everything Nate has sad is correct and you
should listen to him ;)
-mike