This seems to not work on the msys mingw builds. Example

This seems to not work on the msys mingw builds. Example

I know next to nothing about Windows. But PKG_INSTALLDIR was added in pkg-config 0.27, I guess msys1 uses something older than that. I'm surprised anybody still uses pkg-config < 0.27 (2012-07-11), but not using that macro fixes the issue.

I don't understand the commit message description of why this change is needed or what improvements it gives. Can you describe what use case this improves?

There is a typo in the description (which I'm not fixing right now to save CI builds, in case there is any further feedback). It should be "supposes", not "supposed". It refers to the fact libdir and includedir are described relative to prefix/exec_prefix. So, if for example you run pkg-config with --define-variable=prefix=XXX, it will affect includedir. The alternative would be to describe libdir and includedir relative to pcfiledir, which would be more correct if you suppose that when people use "./configure --libdir=YYY" YYY is something completely independent of exec_prefix.

The use case this improves is:

• You are building libcurl for an embedded device
• You use the default prefix/libdir/includedir because that's where it's going to be installed in the embedded device firmware
• You do make install DESTDIR=$STAGING_DIRECTORY
• You try to build something using the libcurl in the staging directory.

Since the libcurl.pc in the staging directory says the libraries are in /usr/lib, not in $STAGING_DIRECTORY/usr/lib, things break.

There is PKG_CONFIG_SYSROOT_DIR, but that isn't always enough. You can end up with situations where stuff is installed in more than one single "sysroot" directory and whatever. The result is that people end up creating pkg-config wrapper scripts (e.g. https://github.com/openwrt/openwrt/blob/master/tools/pkgconf/files/pkg-config) and other hacks.

Once everything is relative to the libcurl.pc file path the problem goes away.

For my standard build, this PR breaks libcurl.pc. I run configure like this:

./configure ... --prefix=$HOME/test-curl-install ...

and without this PR, the resulting libcurl.pc two top variables look like this:

prefix=/home/daniel/test-curl-install
exec_prefix=${prefix}

but with this PR applied, I instead get the two lines to look like this:

prefix=${pcfiledir}/../..
exec_prefix=${pcfiledir}/../..

Is $(pcfiledir) a magic variable for pkg-config? But even so, the prefix doesn't at all point out the dir in which I will install this build...

Is $(pcfiledir) a magic variable for pkg-config?

Yes: https://cgit.freedesktop.org/pkg-config/tree/pkg-config.1?id=925119ce512a05f4c64049526aa19b1296b55e3e#n329

But even so, the prefix doesn't at all point out the dir in which I will install this build...

What do you mean? Supposedly the file will have been installed in /home/daniel/test-curl-install/lib/pkgconfig/libcurl.pc. So pcfiledir is /home/daniel/test-curl-install/lib/pkgconfig and /home/daniel/test-curl-install/lib/pkgconfig/../.. is /home/daniel/test-curl-install.

Isn't PKG_CONFIG_PATH=/home/daniel/test-curl-install/lib/pkgconfig pkg-config --libs libcurl not pointing to the directory where libcurl.so is installed??

I had no idea. Do you know if this $(pcfiledir) variable support something that's been around for a long time too? I mean so that we don't try to lean on something that is too modern for conservative users?

I don't know the details. But at least since 2013 (https://cgit.freedesktop.org/pkg-config/commit/pkg-config.1?id=925119ce512a05f4c64049526aa19b1296b55e3e).

The http://pkgconf.org/ man pages don't document the variable. But it works in my computer.

Thanks!