Traditionally, pkg-config contained Autoconf macros which set *_CFLAGS and *_LIBS. But Automake manual explains that a better granularity shall be maintained: - *_CPPFLAGS for all preprocessor options, mainly -I and -D - *_CFLAGS for other C compiler flags - *_LDADD (or *_LIBADD) for -l and -L options (and for Libtool options -dlopen and -dlpreopen) - LDFLAGS for other linker flags It would be nice if the fields in pkg-config description could match this structure. Recent pkg-config releases try to solve the problem by options which would filter out the options for the old data structure: There are --libs-only-l, --libs-only-L, and --libs-only-other. This means that to get the variable for *_LDADD, you need to call pkg-config twice. And for cflags there are --clags-only-I and --cflags-only-other. To get the right values for *_CPPFLAGS and *_CFLAGS, pkg-config has to be modified: new option --cflags-only-D is needed and the semantics of --cflags-only-other has to be modified accordingly. Moreover, the macros in pkg.m4 provide little help whe one wants to use these options. I hesitate to write the m4 code corresponding to the above as I'm not convinced the jungle of *-only-* options is the right way to go. As you see, this is not a well thought-out suggestion. Sorry. It only a dump of uneasy feelings of an autotools zealot; I hope it helps somehow anyway. :-)
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.