Fails to build with meson 1.3.0 rc1 due to broken bash-completion handling #609
Comments
|
I'm not completely positive what to do here. Obviously, meson 1.3.0 fails to successfully run |
|
Does Meson provide a way to do what the author of this code was clearly trying to do, namely define two variables? |
|
I'm very tempted to resolve this by not using |
I am not too sure that defining two variables was a useful thing for the author of this code to do, honestly. The definition that this code was trying to make for datadir (which was
|
|
ping. I want to resolve this one way or another in time for the final meson release, but I'm not sure what the correct solution is. I'm trying to decide whether:
If there is something I'm missing about defining two defines, I'd be happy to hear it -- at the moment I'm inclined to choose option 1. |
|
I think the reasoning for this may have been that current versions of bash-completion have
That's fine, the intention is to get everything installed by bubblewrap to be below bubblewrap's prefix, even if that differs from bash-completion's prefix (for example
That's fine, the definition used for The only time our redefinition of |
|
Gotcha, thanks for clarifying. I agree this makes sense and should be possible, so that's what I'll do. |
It was previously impossible to do this:
```
dep.get_pkgconfig_variable(
'foo',
define_variable: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
since get_pkgconfig_variable mandated exactly two (if any) arguments.
However, you could do this:
```
dep.get_variable(
'foo',
pkgconfig_define: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
It would silently do the wrong thing, by defining "prefix" as
`/usr=datadir=/usr/share`, which might not "matter" if only datadir was
used in the "foo" variable as the unmodified value might be adequate.
The actual intention of anyone writing such a meson.build is that they
aren't sure whether the .pc file uses ${prefix} or ${datadir} (or which
one gets used, might have changed between versions of that .pc file,
even).
A recent refactor made this into a hard error, which broke some projects
that were doing this and inadvertently depending on some .pc file that
only used the second variable. (This was "fine" since the result was
essentially meaningful, and even resulted in behavior identical to the
intended behavior if both projects were installed into the same prefix
-- in which case there's nothing to remap.)
Re-allow this. There are two ways we could re-allow this:
- ignore it with a warning
- add a new feature to allow actually doing this
Since the use case which triggered this bug actually has a pretty good
reason to want to do this, it makes sense to add the new feature.
Fixes https://bugs.gentoo.org/916576
Fixes containers/bubblewrap#609
It was previously impossible to do this:
```
dep.get_pkgconfig_variable(
'foo',
define_variable: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
since get_pkgconfig_variable mandated exactly two (if any) arguments.
However, you could do this:
```
dep.get_variable(
'foo',
pkgconfig_define: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
It would silently do the wrong thing, by defining "prefix" as
`/usr=datadir=/usr/share`, which might not "matter" if only datadir was
used in the "foo" variable as the unmodified value might be adequate.
The actual intention of anyone writing such a meson.build is that they
aren't sure whether the .pc file uses ${prefix} or ${datadir} (or which
one gets used, might have changed between versions of that .pc file,
even).
A recent refactor made this into a hard error, which broke some projects
that were doing this and inadvertently depending on some .pc file that
only used the second variable. (This was "fine" since the result was
essentially meaningful, and even resulted in behavior identical to the
intended behavior if both projects were installed into the same prefix
-- in which case there's nothing to remap.)
Re-allow this. There are two ways we could re-allow this:
- ignore it with a warning
- add a new feature to allow actually doing this
Since the use case which triggered this bug actually has a pretty good
reason to want to do this, it makes sense to add the new feature.
Fixes https://bugs.gentoo.org/916576
Fixes containers/bubblewrap#609
It was previously impossible to do this:
```
dep.get_pkgconfig_variable(
'foo',
define_variable: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
since get_pkgconfig_variable mandated exactly two (if any) arguments.
However, you could do this:
```
dep.get_variable(
'foo',
pkgconfig_define: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
It would silently do the wrong thing, by defining "prefix" as
`/usr=datadir=/usr/share`, which might not "matter" if only datadir was
used in the "foo" variable as the unmodified value might be adequate.
The actual intention of anyone writing such a meson.build is that they
aren't sure whether the .pc file uses ${prefix} or ${datadir} (or which
one gets used, might have changed between versions of that .pc file,
even).
A recent refactor made this into a hard error, which broke some projects
that were doing this and inadvertently depending on some .pc file that
only used the second variable. (This was "fine" since the result was
essentially meaningful, and even resulted in behavior identical to the
intended behavior if both projects were installed into the same prefix
-- in which case there's nothing to remap.)
Re-allow this. There are two ways we could re-allow this:
- ignore it with a warning
- add a new feature to allow actually doing this
Since the use case which triggered this bug actually has a pretty good
reason to want to do this, it makes sense to add the new feature.
Fixes https://bugs.gentoo.org/916576
Fixes containers/bubblewrap#609
It was previously impossible to do this:
```
dep.get_pkgconfig_variable(
'foo',
define_variable: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
since get_pkgconfig_variable mandated exactly two (if any) arguments.
However, you could do this:
```
dep.get_variable(
'foo',
pkgconfig_define: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
It would silently do the wrong thing, by defining "prefix" as
`/usr=datadir=/usr/share`, which might not "matter" if only datadir was
used in the "foo" variable as the unmodified value might be adequate.
The actual intention of anyone writing such a meson.build is that they
aren't sure whether the .pc file uses ${prefix} or ${datadir} (or which
one gets used, might have changed between versions of that .pc file,
even).
A recent refactor made this into a hard error, which broke some projects
that were doing this and inadvertently depending on some .pc file that
only used the second variable. (This was "fine" since the result was
essentially meaningful, and even resulted in behavior identical to the
intended behavior if both projects were installed into the same prefix
-- in which case there's nothing to remap.)
Re-allow this. There are two ways we could re-allow this:
- ignore it with a warning
- add a new feature to allow actually doing this
Since the use case which triggered this bug actually has a pretty good
reason to want to do this, it makes sense to add the new feature.
Fixes https://bugs.gentoo.org/916576
Fixes containers/bubblewrap#609
Before Meson 1.3.0, this would not do what we meant (instead defining prefix to a wrong value composed from the remaining arguments). The only reason we needed to redefine prefix in the first place is that bash-completion older than 2.10 did not allow users of its pkg-config file to override the datadir used to compute its completionsdir, but that was addressed in version 2.10 (2019). Users of older bash-completion should set bubblewrap's bash_completion_dir build option, if the automatically-discovered default is not appropriate. Related to containers#609 Signed-off-by: Simon McVittie <smcv@collabora.com>
bubblewrap/completions/bash/meson.build
Lines 12 to 18 in 7816e01
In meson 1.2.x, this executes:
Which achieves nothing in the way of passing pkgconfig defines. completionsdir doesn't get datadir redefined, so it prints completionsdir unmodified.
In meson 1.3.0 due to a refactor this actually simply errors, based on the assumption that "users weren't supposed to do it". There may be some truth to that. If you'd flipped the order around, then this would instead be:
On my system, the resulting value of bash_completion_dir would then be:
which is pretty badly broken, I daresay
Discovered in https://bugs.gentoo.org/916576
/cc @thesamesam
The text was updated successfully, but these errors were encountered: