Take host into account when looking for pkg-config#12190
Conversation
|
Two questions:
|
This is to prepare the next commit: when cross-compiling the right pkg-config to use is the one giving information on the host system.
Try ${host}-pkg-config before falling back to pkg-config
|
Gabriel Scherer (2023/04/18 06:14 -0700):
Two questions:
1. why do we have `[pkg-configx]` with a `x` at the end, is this a
typo?
yes, absolutely. Well spotted, thanks. Fixed.
2. what is the use of the `[false]` default value at the end, is it
meant to be checked explicitly before calling pkg-config in the rest
of the configure script? (Or does everything work as expected on
systems where pkg-config is not available, because tests using
`PKG_CONFIG` just fail?)
It's the value that the `PKG_CONFIG` variable should take if the utility
is not found. The value is false because, that way, the calls to
`${PKG_CONFIG}` will call the `false` utility which will return a
non-zero exit code, which will make the configure script fall back to
the case where there is no `pkg-config`.
|
28bc7fb to
bc9c87d
Compare
|
The change looks fine to me after your explanation. Two points:
|
|
Gabriel Scherer (2023/04/18 08:17 -0700):
The change looks fine to me after your explanation. Two points:
1. I think that the CI earlier didn't catch the typo, so I am nervous about disabling the zstd support (at least using pkg-config) without noticing. Could you test manually test that the patch behaves as expect
ed on pkg-config-enabled systems?
Actually, there are two things to test: (1) that pkg-config is found
when it's there and (2) that the host-pkg-config is prioritized if it
exists. the problem was reported to me by @shym so would you mind
testing this, Samuel, please?
2. I wondered if one should leave PKG_CONFIG to its "ambiant" value if
the lookup fails (I think this is what happens if you don't provide an
else branch to AC_PATH_TOOL?),
That's my understanding, too, yes.
which lets user configure the value.
Not really. If you think about something like:
```
PKG_CONFIG=foo ./configure
```
it's discouraged in Autoconf's documentation because it will make the
variable available to all the subshells, which may not be desirable.
If one wanted to give the user the ability to configure which
`pkg-config` program to use, one would need to use the `AC_ARG_VAR`
macro,one would then become able to do:
```
./configure PKG_CONFIG=foo
```
which would pass the value only to the shell running configure and not
to the sub-shells it itself executes.
|
|
I've been bitten by this in the context of compiling a 32-bit OCaml on In this setting the options we have to consider are whether pkg-config
So this is a nice improvement, thank you! |
|
I should have added that the interesting part to look into the logs, as far as this PR is concerned, is probably the "Show configuration and clean up" step, that displays ocamlc -config. |
|
If I understand correctly, if we could say |
|
Thanks @shym for the tests, merging now. |
Take host into account when looking for pkg-config (cherry picked from commit 2725f08)
When cross-compiling (e.g. for the Windows ports), one needs to look
for
${host}-pkg-configin priority, if one wants to find theright instance of
pkg-config.This PR fixes the support for the pkg-config-based detection of zstd.