1 |
On Wed, Jan 6, 2021 at 5:47 PM James Le Cuirot <chewi@g.o> wrote: |
2 |
> |
3 |
> On Mon, 4 Jan 2021 19:28:37 -0500 |
4 |
> Mike Gilbert <floppym@g.o> wrote: |
5 |
> |
6 |
> > On Mon, Jan 4, 2021 at 6:45 PM Mike Gilbert <floppym@g.o> wrote: |
7 |
> > > |
8 |
> > > On Mon, Jan 4, 2021 at 6:18 PM James Le Cuirot <chewi@g.o> wrote: |
9 |
> > > > $ PKG_CONFIG_SYSROOT_DIR=/foo pkg-config --variable=udevdir udev |
10 |
> > > > /lib/udev |
11 |
> > > > |
12 |
> > > > The udevdir variable is not affected by PKG_CONFIG_SYSROOT_DIR at all. |
13 |
> > > > And why would it be? The man page says that this variable is only |
14 |
> > > > applied to -I and -L flags. I don't know for sure but I suspect that |
15 |
> > > > pkg-config just sees this as some arbitrary variable with no special |
16 |
> > > > path handling at all. I wonder what led you to think that this fix was |
17 |
> > > > necessary? |
18 |
> > > |
19 |
> > > Interesting! |
20 |
> > > |
21 |
> > > pkg-config behaves differently on my system: |
22 |
> > > |
23 |
> > > % PKG_CONFIG_SYSROOT_DIR=/foo pkg-config --variable=udevdir udev |
24 |
> > > /foo/lib/udev |
25 |
> > > |
26 |
> > > This appears to be a difference in behavior between dev-util/pkgconfig |
27 |
> > > and dev-util/pkgconf. I am using pkgconf, and I would guess you are |
28 |
> > > using pkgconfig. |
29 |
> > > |
30 |
> > > I guess I will ask pkgconf upstream for help on this; it seems like |
31 |
> > > this is probably an unintended behavior. |
32 |
> > |
33 |
> > It seems that the pkgconf behavior is intentional. |
34 |
> > |
35 |
> > https://github.com/pkgconf/pkgconf/issues/69 |
36 |
> > |
37 |
> > I opened an issue to see if we can get some kind of opt-out. |
38 |
> > |
39 |
> > https://github.com/pkgconf/pkgconf/issues/205 |
40 |
> |
41 |
> Hmmm. At this point, I'm thinking maybe we should just address this in |
42 |
> cross-pkg-config. It seems unfair to ask upstream to accommodate this |
43 |
> when the tool is just doing what we asked it to. Perhaps it could |
44 |
> respect PKG_CONFIG_SYSROOT_DIR if it is already set, even when empty. |
45 |
> It wouldn't allow to you set this differently for the build host but |
46 |
> you shouldn't ever have to. I think I'd prefer this over adding yet |
47 |
> another confusing variable. The same could be applied to |
48 |
> PKG_CONFIG_LIBDIR and PKG_CONFIG_SYSTEM_LIBRARY_PATH for consistency. |
49 |
> What do you think? |
50 |
|
51 |
I like the idea of having cross-pkg-config respect |
52 |
PKG_CONFIG_SYSROOT_DIR from the calling environment (even if it is |
53 |
empty). That's just a more flexible design overall. |
54 |
|
55 |
However, I think there's a fundamental design conflict here. Prefixing |
56 |
all pkgconfig variables that happen to start with a slash is |
57 |
problematic, and the desired result depends on the context in which it |
58 |
will be used. |
59 |
|
60 |
If the result is going to be used to find some existing file in |
61 |
SYSROOT (like the SDK example included in issue 69 from above), then |
62 |
we want it to be prefixed with SYSROOT. |
63 |
|
64 |
If the result is going to be used to install new files, we don't want |
65 |
SYSROOT in the result. The package manager is responsible for |
66 |
prefixing the paths with ROOT when merging the files. |
67 |
|
68 |
We could apply workarounds in ebuilds/eclasses to make this |
69 |
distinction in Gentoo by setting PKG_CONFIG_SYSROOT_DIR selectively. |
70 |
However, I wonder if there is a workable solution to this that could |
71 |
be applied in upstream projects. |