Currently pkg-config on Windows does a little trick where it rewrites the ${prefix} variable at runtime based on the location of the .pc file. This works well enough, so long as the other path variables in the .pc file derive from ${prefix}. It's pretty magical, though.

However, I like this relative path feature a lot since it would be more general. It would be pretty easy to handle by just having pkg-config define a variable for each .pc file. ${cwd} implies the current working directory rather than the directory of the .pc file. We could borrow some parlance from ld.so and make the variable ${ORIGIN} like it uses when following rpath.

Thanks for the information.  Didn't know about the magic on Windows.  For me, I'm cross-compiling, so I have this issue on Linux.  I agree that "cwd" isn't the right name.

Yay for undocumented features! While having a quick look around for where to insert this magic variable, I found out pkg-config already had one. pcfiledir is defined from the location it was found at.

$ cat /tmp/lib/pkgconfig/relpath.pc
prefix=${pcfiledir}/../..
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: Simple test
Description: Dummy pkgconfig test package for testing pkgconfig
Version: 1.0.0
Requires:
Libs: -L${libdir} -lfoo
Cflags: -I${includedir}
$ PKG_CONFIG_PATH=/tmp/lib/pkgconfig pkg-config --cflags relpath
-I/tmp/lib/pkgconfig/../../include

This looks to have been there at least since pkg-config-0.21. I'm going to change this bug to be about documenting pcfiledir.

Fantastic!  Ok.  Then perhaps the harder thing to do would be to change every project to default to ${pcfiledir}/.. instead of ${prefix} when creating their .pc files?

(In reply to comment #4)
> Fantastic!  Ok.  Then perhaps the harder thing to do would be to change
> every project to default to ${pcfiledir}/.. instead of ${prefix} when
> creating their .pc files?

Yeah, that would be the issue. I remember thinking the same thing about the magic prefix mangling on Windows: in order for the feature to work, you're dependent on people writing well formed .pc files. It turns out, though, that the magic prefix feature as written by tml actually handles the case where the variables are already expanded by keeping track of the original value of prefix and replacing that path if it finds it anywhere.

So, there may actually be 2 ways to make a relocatable .pc file: use ${pcfiledir}, use --define-prefix behavior. I actually was working to make that --define-prefix feature available everywhere, if only for the reason that I could actually test the code without having to get on Windows. This just gives a little more motivation. I'm going to open a separate bug to keep track of that and keep this about documenting pcfiledir.

Fixed in 925119c.

What could be useful to help with getting every project to use ${pcfiledir} would be to have the newer PKG_INSTALLDIR m4 module calculate where prefix is relative to ${pcfiledir} and then substitute it as @pkgrel_prefix@ or something. Then fixing your .pc file would be as simple as changing thing @prefix@ substitution. Another day...