Bug 13912

I don't know if "more granularity" is needed as much as "clearer explanations of usage". For example, I don't think I've ever seen a flag other than -I or -D in a .pc Cflags. OTOH, autoconf "CFLAGS" is specifically _C_ flags, not C++ or other languages, so "passing -I in CFLAGS" is not up to spec in two distinct ways. And I also don't remember seeing any Libs other than -L and -l.

I concur that a ton of --something-flags-only seems overkill, since it's rare that anyone cares about only one type of flags in a way that also getting the related ones would interfere. That is, if you're doing .c -> .o compiling or testing for presence of a .h, having -D in addition to the -I doesn't matter.

Why not focus on making pkg-config's interface sync with how it's used:

1. "get me the precompile flags"
2. "get me the linker flags"

Item 1 is CPPFLAGS in automake parlance, is stored in Cflags in the .pc file, and is therefore returned by `pkg-config --cflags`. Other flags qualify as "Cflags" in .pc parlance, but don't appear to be used "in the wild". Item 2 is LDADD or LIBADD in automake parlance and is returned by `pkg-config --libs`. The --cflags and --libs meanings and behaviors (as used and as I understand them, not necessarily as documented) are in sync with the *-config scripts that other libraries use instead of pkg-config.

I mentioned this on the pkg-config mailing list a few days ago, no response there yet.

The pkg.m4 macros should be expanded to better support automake's different handling of LIBS and LDFLAGS. If one throws a flag such as -L/usr/kerberos/lib into a LIBS variable in Makefile.am, for example, automake fails because -L flags don't belong in LIBS. In the other case, where -l and other things belonging in LIBS are put in an automake LDFLAGS variable, some problems described at http://www.gentoo.org/proj/en/qa/asneeded.xml#doc_chap2 happen (i.e., -l flags must be specified after the objects listed).

This categorization of different sorts of flags is useful for readability and, I suppose, debugging in some cases. The same sort of differentiation between CPPFLAGS and CFLAGS probably has some merit in its own right. Implementing this sort of thing directly into PKG_CHECK_MODULES would make configure.ac and Makefile.am writing _much_ easier. It looks like the only option is to use PKG_CHECK_MODULES to 
1) ensure that ./configure fails when the modules don't exist
2) grab _CFLAGS
and then to call _PKG_CONFIG directly to get separate LIBS and LDFLAGS. But I feel like I'm voiding my ``public API usage contract'' (i.e., I'm calling private macros I can call but am not supposed to call...).

CXXFLAGS being distinguished from CFLAGS would probably be overkill, though. If a C++ library needs applications which link to it to be compiled with special flags, there is little likeliness that such a library would have a C API bundled in the same library.

(In reply to comment #2)
> The pkg.m4 macros should be expanded to better support automake's different
> handling of LIBS and LDFLAGS. If one throws a flag such as -L/usr/kerberos/lib
> into a LIBS variable in Makefile.am, for example, automake fails because -L
> flags don't belong in LIBS. In the other case, where -l and other things
> belonging in LIBS are put in an automake LDFLAGS variable, some problems
> described at http://www.gentoo.org/proj/en/qa/asneeded.xml#doc_chap2 happen
> (i.e., -l flags must be specified after the objects listed).

Both -l and -L would go in target_LIBADD (or target_LDADD) not LDFLAGS (according to libtool/automake documentation). Automake places target_LIBADD/LDADD after target_OBJECTS in the linker command, so you should be all set.

> Both -l and -L would go in target_LIBADD (or target_LDADD) not LDFLAGS
> (according to libtool/automake documentation). Automake places
> target_LIBADD/LDADD after target_OBJECTS in the linker command, so you should
> be all set.

Oops, I misread that portion of the documentation. I'll have to look elsewhere to solve my difficulty in setting up my Makefile.am.

However, making some of the features of the pkg-config CLI more accessible to the autoconf macro users likely will be useful in some cases...which I can't think of atm ;-)

People assert that there should be a separation of CFLAGS and CPPFLAGS without explaining why they think so.  What is the problem that is solved by splitting them up?

No response from submitter over what problems this actually solves, rather than vague claims about suppose, probably, maybe fixes something, so closing this bug.