PMS states that in EAPI 8, "--disable-static" must be passed to econf if it appears in the output of configure --help. This is problematic in a couple of ways: 1. For packages using libtool, configure --help outputs a string like this: > --enable-static[=PKGS] build static libraries [default=yes] The string "--disable-static" does not appear. 2. Some packages have configure options like "--enable-static-foo", but not "--enable-static" or "--disable-static". For example, net-vpn/tor has the following configure options: > --enable-static-openssl link against a static openssl library. Requires > --enable-static-libevent > link against a static libevent library. Requires > --enable-static-zlib link against a static zlib library. Requires > --enable-static-tor create an entirely static Tor binary. Requires > Build without support for zstd's "static-only" APIs. Build without support for zstd's "static-only" APIs. The current Portage implementation checks for either *--enable-static* or *--disable-static*. This addresses the first problem, but fails to address the second problem.
> (In reply to Mike Gilbert from comment #0) > PMS states that in EAPI 8, "--disable-static" must be passed to econf if it > appears in the output of configure --help. I meant to write: PMS states that in EAPI 8, econf must pass "--disable-static" to configure if it appears in the output of configure --help.
(In reply to Mike Gilbert from comment #0) > The current Portage implementation checks for either *--enable-static* or > *--disable-static*. That doesn't follow the spec, which explicitly says that --disable-static must occur in the output of configure --help.
The help message produced by LT_INIT in libtool-2.4.6 always says "--enable-static" regardless of the default value, see m4/ltoptions.m4: AC_ARG_ENABLE([static], [AS_HELP_STRING([--enable-static@<:@=PKGS@:>@], [build static libraries @<:@default=]_LT_ENABLE_STATIC_DEFAULT[@:>@])], ...) This means that the behaviour specified by PMS is non-functional. Since the damage is already done by Portage not following the spec, how about retroactively changing PMS to the following wording: "--disable-static, if the EAPI is listed in table 12.8 as using it. This option will only be passed if the string --disable-static or --enable-static occurs in the output of configure --help; the string must not be immediately followed by any of the characters [A-Za-z0-9+_.-]. https://projects.gentoo.org/pms/8/pms.html#x1-12800012.3.8
Created attachment 740970 [details, diff] pkg-mgr-commands.tex: Update condition for econf --disable-static This would be the corresponding patch for the spec. Slightly simplified regexp but shouldn't make any difference in practice.
Created attachment 740982 [details, diff] pkg-mgr-commands.tex: Update condition for econf --disable-static As discussed in #gentoo-pms, let's fix only item 1 for now (i.e. update PMS to follow Portage). Item 2 from comment #0 (fix --enable-static-openssl etc.) can be fixed in the next EAPI. IIUC it is a minor problem and should only cause configure to output a warning that option --disable-static is not available. Fixing it in the next EAPI has the advantage that we can check for a proper end of the option name for all options where we test --help output.
I've tried digging a bit to figure out how we ended up with this... and I'm afraid I haven't been able to find anything specific. I suspect a major cause of all this was the huge delay between my first efforts at implementing preliminary EAPI 8 features back in 2020, and the fast-effort in 2021. FWICS the Portage behavior of matching disable and enable was part of the original patch that predates the PMS. I suspect that I've noticed the first problem during initial testing and updated the patch to account for it. However, that information doesn't seem to have made back into the bug, and it seems that we failed to notice while working on the PMS. For EAPI 8, I think we should update PMS to match Portage behavior. After all, that was the intended and tested behavior from day one. The PMS/PkgCore implementation is not really meaningful given that it simply doesn't work on the majority of packages. This has the obvious advantage that packages behave consistently independently of Portage version. On the other hand, I wouldn't change it to account for possible other option names today. This really sounds like a corner case of a corner case, and I think the gain here doesn't justify making things more inconsistent here. For EAPI 9, I think we should go for consistency all the way. That is: a. make all --enable options match either --enable or --disable (should we do that for --with and --without too?) b. state that when matching option names in --help output, they 'must [not] be followed by ...'
(In reply to Michał Górny from comment #6) > For EAPI 9, I think we should go for consistency all the way. That is: > > a. make all --enable options match either --enable or --disable (should we > do that for --with and --without too?) > > b. state that when matching option names in --help output, they 'must [not] > be followed by ...' While I agree to item b, I'd rather not open the can of worms that comes with item a (which would affect --with-sysroot, --disable-dependency-tracking and --disable-silent-rules AFAICS). Is there a single case known where configure --help outputs the "enable" variant for these (with enable being the default)?
(In reply to Ulrich Müller from comment #7) > Is there a single case known where configure --help outputs the "enable" > variant for these (with enable being the default)? This should read "outputs _only_ the 'enable' variant".
PkgCore update ready.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/pms.git/commit/?id=8ce3a9c94407c8bfcf27c8455fac32d3a38fc981 commit 8ce3a9c94407c8bfcf27c8455fac32d3a38fc981 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2021-09-24 12:12:38 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2021-09-24 13:06:45 +0000 pkg-mgr-commands.tex: Update condition for econf --disable-static The help message produced by LT_INIT in libtool-2.4.6 always says --enable-static regardless of the default value, see m4/ltoptions.m4: AC_ARG_ENABLE([static], [AS_HELP_STRING([--enable-static@<:@=PKGS@:>@], [build static libraries @<:@default=]_LT_ENABLE_STATIC_DEFAULT[@:>@])], ...) This means that looking only for --disable-static in output of configure --help results in non-functional behaviour. Implementation in Portage (which predates the PMS wording) looks for --enable-static in addition. Bug: https://bugs.gentoo.org/814368 Signed-off-by: Ulrich Müller <ulm@gentoo.org> pkg-mgr-commands.tex | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Closing. I have filed bug 815169 for the followup change in EAPI 9.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/pms.git/commit/?id=e0aa80cc0d28a25bfc68b4671771083e282f6ba2 commit e0aa80cc0d28a25bfc68b4671771083e282f6ba2 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2022-11-19 20:22:34 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2022-11-19 20:22:34 +0000 pkg-mgr-commands.tex: Update condition for econf --disable-static (again) The intention is to pass --disable-static, in order to (only) disable static libtool archive building. The current condition asks for either of --{disable,enable}-static in configure --help output, which causes false positives: https://archives.gentoo.org/gentoo-portage-dev/message/efc3f424d1dffd3415da538ec25532a9 Therefore, narrow the condition to require both --enable-static and --enable-shared. In addition, backport the check for proper end of string from the EAPI 9 feature list, but restrict it to this option for now. Bug: https://bugs.gentoo.org/814368 Bug: https://bugs.gentoo.org/815169 Signed-off-by: Ulrich Müller <ulm@gentoo.org> pkg-mgr-commands.tex | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
