On Wed, Feb 10, 2016 at 11:03:04AM +0100, Bastien ROUCARIES wrote: > On Wed, Feb 10, 2016 at 10:59 AM, Alastair McKinstry > > In particular, for any non-standard variables, you can read them, by eg: > > > > f90_compiler=$(pkg-config mypkg --variable=f90_compiler) > > > > Its probably a good idea to document the config script as deprecated > > in output, the man page, etc. > > (2) wrapper are not cross build safe...
This seems less than constructive, so let me briefly follow up on how to make it work properly. The first misconception I see in this thread is that somehow pkg-config is good and foo-config is bad. It's not as simple as that. Have a look at libpython3-dev. It ships e.g. x86_64-linux-gnu-python3-config. By prefixing the script with the triplet, we can treat it very much like libraries that are being placed in multiarch locations. In order for pkg-config to be "better" than your foo-config script, you need to tell it about the current host architecture by prefixing it with the triplet. Instead of calling pkg-config, you should be calling $DEB_HOST_GNU_TYPE-pkg-config. The tricky question is: Where to obtain that value. The answer is: By parsing $0. So when converting your foo-config scripts to use pkg-config, you can go ahead and parse $0. Use that triplet instead of encoding it into your script. Then each libfoo-dev instance can place the same (shared) foo-config script in a shared location and place individual symbolic links with the prefix at it. Alternatively, you can do like python and ship plain files in triplet-prefixed locations. No pkg-config. Still M-A:same safe. It is worth noting that pkg-config has a head-start here. It implements the parsing of $0 for you. It also improves the client side. For this change to work properly, consumers must call your foo-config with the triplet prefix. When you use autotools, it'll automatically prefer the prefixed pkg-config over the plain one (unless your pkg-config code is home-grown). It's not like pkg-config is the silver bullet here. It just helps you solve some of the integration problems. Finally, turning Multi-Arch off for libfoo-dev packages may sound bad, but in many cases it is actually harmless to practical cross building. libgpg-error-dev has it turned off and still works well in practise. There is a trade-off between backwards compatibility, multiarch support and time investment to be made in these cases. I do not believe that pkg-config is the one-size-fits-all answer. Helmut