Re: How to change config script for multiarch?
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
Reply to: