$ pkg-config --variable=my_magic_flag --cflags mypkg -foo-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include while more reasonable output would be: -foo -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
I think this is really undefined behaviour. In pkgconf, I have implemented it where --variable overrides --cflags/--libs which I think is more sensible. The fact that over 30000 packages are successfully built with pkgconf would indicate that nobody is depending on --variable working in the same request as --cflags or --libs.
(In reply to comment #1) > I think this is really undefined behaviour. In pkgconf, I have implemented it > where --variable overrides --cflags/--libs which I think is more sensible. The > fact that over 30000 packages are successfully built with pkgconf would > indicate that nobody is depending on --variable working in the same request as > --cflags or --libs. Which doesn't mean someone couldn't finally make some reasonable use of it, as it is defined now.
I concur with William that allowing these options together is not useful, and clearly no one has been doing that or they would have had broken output. I've implemented a fix that enforces only one output option at a time with a couple exceptions. 1. Any combination of --cflags* and --libs*. 2. --print-requires and --print-requires-private (I know the fedora rpm pkg-config find-requires script used to call them both simultaneously) 3. --exists and --atleast/exact/max-version. Everything else seems really dubious to try to use simultaneously because you'd have no idea what delimited the output of one option from the other. We'll see if this is too conservative after the next release. Fixed in commit d1b7dd4. Thanks for the report.
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.