Behavior of --define-variable=VARIABLENAME=VARIABLEVALUE & PKG_CONFIG_SYSROOT_DIR

[Colin Close]

Hi,

I'm new to this list and hope that this question has not been asked before.
Please excuse the long explanation but it is important to make the problem clear.
I am building an autoconf system which uses pkg-config quite intensly the configure 
package being built also supports cross-compiling with mingw32 on the native linux 
system.
The portability of the configure tools in the cross-compiling mode makes the use of pkg-
config more complex since the pc files will exist in different directories than the 
native pc files. I have overcome this by using configure to create a shell scripts which 
sets the search environment variables appropriately and this works well. 
However a problem has arisen in relation to the {prefix} variable.
Quite often when cross-compiling the libraries required to build a package will be 
obtained as downloaded binaries. These are usually placed in a subdirectory of the 
mingw32 directory. This mingw32 directory may also be a symbolic link on some other 
filesystem like /opt for example.
The {prefix} in the downloaded binaries is unlikely to match the installed directory 
since they will have been compiled on some other system so if pkg-config is run on a 
package to return the cflags for example, the prefix will be incorrect. I have tried to 
overccome this by modifying the pkg-config m4 macros such that I can run a line such as 
the following:-
$PKG_CONFIG --exists --print-errors "gtk+-2.0 >= 2.4.0 --define-variable=prefix=/opt"'

Looks good doesn't it but alas here is the output:-

GTK_CFLAGS='-I/opt/include/gtk-2.0 -I/opt/lib/gtk-2.0/include -I/opt/include/atk-1.0 -
I/opt/include/cairo -I/opt/include/pango-1.0 -I/usr/i586-pc-mingw32/sys-
root/mingw/include/glib-2.0 -I/usr/i586-pc-mingw32/sys-root/mingw/lib/glib-2.0/include -
I/usr/i586-pc-mingw32/sys-root/mingw/include/freetype2 -I/usr/i586-pc-mingw32/sys-
root/mingw/include -I/opt/include -I/usr/i586-pc-mingw32/sys-root/mingw/include/libpng12

The gtk libraries have been set with the new {prefix} but the Requires: libraries have 
not thus I need to have to run a second and possibly third iteration of pkg-config to 
ensure I get the correct flags. This behaviour ultimately leads to very long and hard to 
decipher gcc command lines which is not ideal for portability.

Since I had control over the environment variables I tried to use PKG_CONFIG_SYSROOT_DIR 
in combination with the define-variable strategy in an attempt to get the correct 
output.

Here is what I got:-
GTK_CFLAGS='-I/opt/opt/include/gtk-2.0 -I/opt/opt/lib/gtk-2.0/include -
I/opt/opt/include/atk-1.0 -I/opt/opt/include/cairo -I/opt/opt/include/pango-1.0 -
I/opt/usr/i586-pc-mingw32/sys-root/mingw/include/glib-2.0 -I/opt/usr/i586-pc-
mingw32/sys-root/mingw/lib/glib-2.0/include -I/opt/usr/i586-pc-mingw32/sys-
root/mingw/include/freetype2 -I/opt/usr/i586-pc-mingw32/sys-root/mingw/include -
I/opt/opt/include -I/opt/usr/i586-pc-mingw32/sys-root/mingw/include/libpng12

Definitely not the right answer!!!

I tried various other "cheats" but always with the result that the requires libs always 
retained their {prefix}. Now its clear from the output that pkg-config actually checks 
the pc files for the Requires: so is there any reason why it does not change the prefix 
for those also. I think this may be a bug but it could also be intended behaviour; if it 
is intended is it possible before your release 0.24 to provide a switch to allow the 
requires to have the requires prefix switched too. Alternatively an "--without-requires" 
switch would perhaps give some flexibility. 
Alternatively if anyone knows a way around this difficulty I would be delighted to hear 
from them!!

Best

Colin Close