* [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac @ 2017-06-10 11:28 Jeroen Roovers 2017-06-10 12:04 ` Sergei Trofimovich 0 siblings, 1 reply; 15+ messages in thread From: Jeroen Roovers @ 2017-06-10 11:28 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 46 bytes --] https://bugs.gentoo.org/show_bug.cgi?id=426262 [-- Attachment #2: 426262-autotools.eclass-deprecated-configure.in.patch --] [-- Type: text/x-patch, Size: 1018 bytes --] diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass index 2710bf827b..76a5c2eade 100644 --- a/eclass/autotools.eclass +++ b/eclass/autotools.eclass @@ -341,10 +341,11 @@ eautoconf() { echo die "No configure.{ac,in} present!" fi - if [[ ${WANT_AUTOCONF} != "2.1" && -e configure.in ]] ; then - eqawarn "This package has a configure.in file which has long been deprecated. Please" - eqawarn "update it to use configure.ac instead as newer versions of autotools will die" - eqawarn "when it finds this file. See https://bugs.gentoo.org/426262 for details." + if [[ ${WANT_AUTOCONF} != "2.1" && -e configure.in && ! -e configure.ac ]] ; then + eqawarn "This package has a configure.in file which has long been deprecated. Since no" + eqawarn "configure.ac is present either, we rename configure.in to configure.ac. If" + eqawarn "this causes problems, please file a bug report and make it block bug #426262." + mv configure.{in,ac} || die fi autotools_run_tool --at-m4flags autoconf "$@" ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac 2017-06-10 11:28 [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac Jeroen Roovers @ 2017-06-10 12:04 ` Sergei Trofimovich 2017-06-11 15:00 ` William Hubbs 0 siblings, 1 reply; 15+ messages in thread From: Sergei Trofimovich @ 2017-06-10 12:04 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 198 bytes --] On Sat, 10 Jun 2017 13:28:19 +0200 Jeroen Roovers <jer@gentoo.org> wrote: > https://bugs.gentoo.org/show_bug.cgi?id=426262 > + mv configure.{in,ac} || die Looks good. -- Sergei [-- Attachment #2: Цифровая подпись OpenPGP --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac 2017-06-10 12:04 ` Sergei Trofimovich @ 2017-06-11 15:00 ` William Hubbs 2017-06-11 15:07 ` Mart Raudsepp 0 siblings, 1 reply; 15+ messages in thread From: William Hubbs @ 2017-06-11 15:00 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 611 bytes --] On Sat, Jun 10, 2017 at 01:04:06PM +0100, Sergei Trofimovich wrote: > On Sat, 10 Jun 2017 13:28:19 +0200 > Jeroen Roovers <jer@gentoo.org> wrote: > > > https://bugs.gentoo.org/show_bug.cgi?id=426262 > > > + mv configure.{in,ac} || die > > Looks good. > > -- > > Sergei -1 I think this should be handled by the packages, not at the eclass level. https://bugs.gentoo.org/show_bug.cgi?id=426262#c3 The packages should either mv the configure.in to configure.ac internally, or better yet, the maintainers should ask upstream for their packages to fix it. Thanks, William [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac 2017-06-11 15:00 ` William Hubbs @ 2017-06-11 15:07 ` Mart Raudsepp 2017-06-11 15:12 ` Kristian Fiskerstrand 0 siblings, 1 reply; 15+ messages in thread From: Mart Raudsepp @ 2017-06-11 15:07 UTC (permalink / raw To: gentoo-dev Ühel kenal päeval, P, 11.06.2017 kell 10:00, kirjutas William Hubbs: > On Sat, Jun 10, 2017 at 01:04:06PM +0100, Sergei Trofimovich wrote: > > On Sat, 10 Jun 2017 13:28:19 +0200 > > Jeroen Roovers <jer@gentoo.org> wrote: > > > > > https://bugs.gentoo.org/show_bug.cgi?id=426262 > > > + mv configure.{in,ac} || die > > > > Looks good. > > > > -- > > > > Sergei > > -1 > > I think this should be handled by the packages, not at the eclass > level. > > https://bugs.gentoo.org/show_bug.cgi?id=426262#c3 > > The packages should either mv the configure.in to configure.ac > internally, or better yet, the maintainers should ask upstream for > their > packages to fix it. +1, otherwise we will never be able to add/unmask a newer autoconf that doesn't look at configure.in anymore, once such a version eventually happens. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac 2017-06-11 15:07 ` Mart Raudsepp @ 2017-06-11 15:12 ` Kristian Fiskerstrand 2017-06-11 15:17 ` Mart Raudsepp 2017-06-11 15:24 ` David Seifert 0 siblings, 2 replies; 15+ messages in thread From: Kristian Fiskerstrand @ 2017-06-11 15:12 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 1302 bytes --] On 06/11/2017 05:07 PM, Mart Raudsepp wrote: > Ühel kenal päeval, P, 11.06.2017 kell 10:00, kirjutas William Hubbs: >> On Sat, Jun 10, 2017 at 01:04:06PM +0100, Sergei Trofimovich wrote: >>> On Sat, 10 Jun 2017 13:28:19 +0200 >>> Jeroen Roovers <jer@gentoo.org> wrote: >>> >>>> https://bugs.gentoo.org/show_bug.cgi?id=426262 >>>> + mv configure.{in,ac} || die >>> >>> Looks good. >>> >>> -- >>> >>> Sergei >> >> -1 >> >> I think this should be handled by the packages, not at the eclass >> level. >> >> https://bugs.gentoo.org/show_bug.cgi?id=426262#c3 >> >> The packages should either mv the configure.in to configure.ac >> internally, or better yet, the maintainers should ask upstream for >> their >> packages to fix it. > > +1, otherwise we will never be able to add/unmask a newer autoconf that > doesn't look at configure.in anymore, once such a version eventually > happens. > We can always patch the eclass at that point if that is still a big concern, but I fundamentally agree with William on this, starting point should be fixing it upstream, so can start with a tracking bug on affected packages. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac 2017-06-11 15:12 ` Kristian Fiskerstrand @ 2017-06-11 15:17 ` Mart Raudsepp 2017-06-11 15:20 ` Kristian Fiskerstrand 2017-06-11 15:24 ` David Seifert 1 sibling, 1 reply; 15+ messages in thread From: Mart Raudsepp @ 2017-06-11 15:17 UTC (permalink / raw To: gentoo-dev Ühel kenal päeval, P, 11.06.2017 kell 17:12, kirjutas Kristian Fiskerstrand: > On 06/11/2017 05:07 PM, Mart Raudsepp wrote: > > Ühel kenal päeval, P, 11.06.2017 kell 10:00, kirjutas William > > Hubbs: > > > On Sat, Jun 10, 2017 at 01:04:06PM +0100, Sergei Trofimovich > > > wrote: > > > > On Sat, 10 Jun 2017 13:28:19 +0200 > > > > Jeroen Roovers <jer@gentoo.org> wrote: > > > > > > > > > https://bugs.gentoo.org/show_bug.cgi?id=426262 > > > > > + mv configure.{in,ac} || die > > > > > > > > Looks good. > > > > > > > > -- > > > > > > > > Sergei > > > > > > -1 > > > > > > I think this should be handled by the packages, not at the eclass > > > level. > > > > > > https://bugs.gentoo.org/show_bug.cgi?id=426262#c3 > > > > > > The packages should either mv the configure.in to configure.ac > > > internally, or better yet, the maintainers should ask upstream > > > for > > > their > > > packages to fix it. > > > > +1, otherwise we will never be able to add/unmask a newer autoconf > > that > > doesn't look at configure.in anymore, once such a version > > eventually > > happens. > > > > We can always patch the eclass at that point if that is still a big > concern, but I fundamentally agree with William on this, starting > point > should be fixing it upstream, so can start with a tracking bug on > affected packages. That's a complete useless waste of time, to track some ancient packages that don't get any upstream update anyway. The active ones have updated it long ago. And it'd be a joke to propose last riting for the reason of a file being named configure.in instead of configure.ac. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac 2017-06-11 15:17 ` Mart Raudsepp @ 2017-06-11 15:20 ` Kristian Fiskerstrand 2017-06-11 15:36 ` Alexis Ballier 0 siblings, 1 reply; 15+ messages in thread From: Kristian Fiskerstrand @ 2017-06-11 15:20 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 829 bytes --] On 06/11/2017 05:17 PM, Mart Raudsepp wrote: >> We can always patch the eclass at that point if that is still a big >> concern, but I fundamentally agree with William on this, starting >> point >> should be fixing it upstream, so can start with a tracking bug on >> affected packages. > That's a complete useless waste of time, to track some ancient packages > that don't get any upstream update anyway. The active ones have updated > it long ago. And it'd be a joke to propose last riting for the reason > of a file being named configure.in instead of configure.ac. > > That determination can be made on a package-by-package basis and fixed in ebuild if needed. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac 2017-06-11 15:20 ` Kristian Fiskerstrand @ 2017-06-11 15:36 ` Alexis Ballier 0 siblings, 0 replies; 15+ messages in thread From: Alexis Ballier @ 2017-06-11 15:36 UTC (permalink / raw To: gentoo-dev On Sun, 11 Jun 2017 17:20:49 +0200 Kristian Fiskerstrand <k_f@gentoo.org> wrote: > On 06/11/2017 05:17 PM, Mart Raudsepp wrote: > >> We can always patch the eclass at that point if that is still a big > >> concern, but I fundamentally agree with William on this, starting > >> point > >> should be fixing it upstream, so can start with a tracking bug on > >> affected packages. > > That's a complete useless waste of time, to track some ancient > > packages that don't get any upstream update anyway. The active ones > > have updated it long ago. And it'd be a joke to propose last riting > > for the reason of a file being named configure.in instead of > > configure.ac. > > > > > > That determination can be made on a package-by-package basis and fixed > in ebuild if needed. > Funny thing is that packages still using autoconf 2.1* don't get any warning and packages setting WANT_AUTOCONF to some older version will never break... ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac 2017-06-11 15:12 ` Kristian Fiskerstrand 2017-06-11 15:17 ` Mart Raudsepp @ 2017-06-11 15:24 ` David Seifert 2017-06-11 15:35 ` Kristian Fiskerstrand 1 sibling, 1 reply; 15+ messages in thread From: David Seifert @ 2017-06-11 15:24 UTC (permalink / raw To: gentoo-dev On Sun, 2017-06-11 at 17:12 +0200, Kristian Fiskerstrand wrote: > On 06/11/2017 05:07 PM, Mart Raudsepp wrote: > > Ühel kenal päeval, P, 11.06.2017 kell 10:00, kirjutas William > > Hubbs: > > > On Sat, Jun 10, 2017 at 01:04:06PM +0100, Sergei Trofimovich > > > wrote: > > > > On Sat, 10 Jun 2017 13:28:19 +0200 > > > > Jeroen Roovers <jer@gentoo.org> wrote: > > > > > > > > > https://bugs.gentoo.org/show_bug.cgi?id=426262 > > > > > + mv configure.{in,ac} || die > > > > > > > > Looks good. > > > > > > > > -- > > > > > > > > Sergei > > > > > > -1 > > > > > > I think this should be handled by the packages, not at the eclass > > > level. > > > > > > https://bugs.gentoo.org/show_bug.cgi?id=426262#c3 > > > > > > The packages should either mv the configure.in to configure.ac > > > internally, or better yet, the maintainers should ask upstream > > > for > > > their > > > packages to fix it. > > > > +1, otherwise we will never be able to add/unmask a newer autoconf > > that > > doesn't look at configure.in anymore, once such a version > > eventually > > happens. > > > > We can always patch the eclass at that point if that is still a big > concern, but I fundamentally agree with William on this, starting > point > should be fixing it upstream, so can start with a tracking bug on > affected packages. > Here's a deal: you can start filing + fixing them. David ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac 2017-06-11 15:24 ` David Seifert @ 2017-06-11 15:35 ` Kristian Fiskerstrand 2017-06-11 16:12 ` William Hubbs 0 siblings, 1 reply; 15+ messages in thread From: Kristian Fiskerstrand @ 2017-06-11 15:35 UTC (permalink / raw To: gentoo-dev, David Seifert [-- Attachment #1.1: Type: text/plain, Size: 1010 bytes --] On 06/11/2017 05:24 PM, David Seifert wrote: >> We can always patch the eclass at that point if that is still a big >> concern, but I fundamentally agree with William on this, starting >> point >> should be fixing it upstream, so can start with a tracking bug on >> affected packages. >> > Here's a deal: you can start filing + fixing them. > The [tracker] is already started, it was determined to add QA warning with info on filing upstream bugs in [bug 426262] and the proper solution is again iterated in [bug 546614], so its not like this is a new approach that is being suggested, but sure, we should all file bugs when we encounter them. References: [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632 [bug 426262] https://bugs.gentoo.org/show_bug.cgi?id=426262 [bug 546614] https://bugs.gentoo.org/show_bug.cgi?id=546614 -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac 2017-06-11 15:35 ` Kristian Fiskerstrand @ 2017-06-11 16:12 ` William Hubbs 2017-06-11 16:14 ` Mart Raudsepp 0 siblings, 1 reply; 15+ messages in thread From: William Hubbs @ 2017-06-11 16:12 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1178 bytes --] On Sun, Jun 11, 2017 at 05:35:53PM +0200, Kristian Fiskerstrand wrote: > On 06/11/2017 05:24 PM, David Seifert wrote: > >> We can always patch the eclass at that point if that is still a big > >> concern, but I fundamentally agree with William on this, starting > >> point > >> should be fixing it upstream, so can start with a tracking bug on > >> affected packages. > >> > > Here's a deal: you can start filing + fixing them. > > > > The [tracker] is already started, it was determined to add QA warning > with info on filing upstream bugs in [bug 426262] and the proper > solution is again iterated in [bug 546614], so its not like this is a > new approach that is being suggested, but sure, we should all file bugs > when we encounter them. > > References: > [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632 > > [bug 426262] > https://bugs.gentoo.org/show_bug.cgi?id=426262 > > [bug 546614] > https://bugs.gentoo.org/show_bug.cgi?id=546614 It seems that the proper fix to this, even for a package that won't do the fix upstream is to use WANT_AUTOCONF in the ebuild to force the version of autoconf you need. Thanks, William [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac 2017-06-11 16:12 ` William Hubbs @ 2017-06-11 16:14 ` Mart Raudsepp 2017-06-11 18:08 ` William Hubbs 0 siblings, 1 reply; 15+ messages in thread From: Mart Raudsepp @ 2017-06-11 16:14 UTC (permalink / raw To: gentoo-dev Ühel kenal päeval, P, 11.06.2017 kell 11:12, kirjutas William Hubbs: > On Sun, Jun 11, 2017 at 05:35:53PM +0200, Kristian Fiskerstrand > wrote: > > On 06/11/2017 05:24 PM, David Seifert wrote: > > > > We can always patch the eclass at that point if that is still a > > > > big > > > > concern, but I fundamentally agree with William on this, > > > > starting > > > > point > > > > should be fixing it upstream, so can start with a tracking bug > > > > on > > > > affected packages. > > > > > > > > > > Here's a deal: you can start filing + fixing them. > > > > > > > The [tracker] is already started, it was determined to add QA > > warning > > with info on filing upstream bugs in [bug 426262] and the proper > > solution is again iterated in [bug 546614], so its not like this is > > a > > new approach that is being suggested, but sure, we should all file > > bugs > > when we encounter them. > > > > References: > > [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632 > > > > [bug 426262] > > https://bugs.gentoo.org/show_bug.cgi?id=426262 > > > > [bug 546614] > > https://bugs.gentoo.org/show_bug.cgi?id=546614 > > It seems that the proper fix to this, even for a package that won't > do > the fix upstream is to use WANT_AUTOCONF in the ebuild to force the > version of autoconf you need. No. It appears you don't know how WANT_AUTOCONF works. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac 2017-06-11 16:14 ` Mart Raudsepp @ 2017-06-11 18:08 ` William Hubbs 2017-06-11 20:02 ` Mart Raudsepp 0 siblings, 1 reply; 15+ messages in thread From: William Hubbs @ 2017-06-11 18:08 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 2001 bytes --] On Sun, Jun 11, 2017 at 07:14:52PM +0300, Mart Raudsepp wrote: > Ühel kenal päeval, P, 11.06.2017 kell 11:12, kirjutas William Hubbs: > > On Sun, Jun 11, 2017 at 05:35:53PM +0200, Kristian Fiskerstrand > > wrote: > > > On 06/11/2017 05:24 PM, David Seifert wrote: > > > > > We can always patch the eclass at that point if that is still a > > > > > big > > > > > concern, but I fundamentally agree with William on this, > > > > > starting > > > > > point > > > > > should be fixing it upstream, so can start with a tracking bug > > > > > on > > > > > affected packages. > > > > > > > > > > > > > Here's a deal: you can start filing + fixing them. > > > > > > > > > > The [tracker] is already started, it was determined to add QA > > > warning > > > with info on filing upstream bugs in [bug 426262] and the proper > > > solution is again iterated in [bug 546614], so its not like this is > > > a > > > new approach that is being suggested, but sure, we should all file > > > bugs > > > when we encounter them. > > > > > > References: > > > [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632 > > > > > > [bug 426262] > > > https://bugs.gentoo.org/show_bug.cgi?id=426262 > > > > > > [bug 546614] > > > https://bugs.gentoo.org/show_bug.cgi?id=546614 > > > > It seems that the proper fix to this, even for a package that won't > > do > > the fix upstream is to use WANT_AUTOCONF in the ebuild to force the > > version of autoconf you need. > > No. It appears you don't know how WANT_AUTOCONF works. From the eclass: # @ECLASS-VARIABLE: WANT_AUTOCONF # @DESCRIPTION: # The major version of autoconf your package needs That leads me to believe that you can set WANT_AUTOCONF="someversion" in your ebuild and your package will use that version of autoconf. If that's wrong, it needs to be fixed and that's a different bug entirely, but it doesn't change my position on adding this particular change to autotools.eclass. William [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac 2017-06-11 18:08 ` William Hubbs @ 2017-06-11 20:02 ` Mart Raudsepp 2017-09-21 14:14 ` Ian Stakenvicius 0 siblings, 1 reply; 15+ messages in thread From: Mart Raudsepp @ 2017-06-11 20:02 UTC (permalink / raw To: gentoo-dev Ühel kenal päeval, P, 11.06.2017 kell 13:08, kirjutas William Hubbs: > On Sun, Jun 11, 2017 at 07:14:52PM +0300, Mart Raudsepp wrote: > > Ühel kenal päeval, P, 11.06.2017 kell 11:12, kirjutas William > > Hubbs: > > > On Sun, Jun 11, 2017 at 05:35:53PM +0200, Kristian Fiskerstrand > > > wrote: > > > > On 06/11/2017 05:24 PM, David Seifert wrote: > > > > > > We can always patch the eclass at that point if that is > > > > > > still a > > > > > > big > > > > > > concern, but I fundamentally agree with William on this, > > > > > > starting > > > > > > point > > > > > > should be fixing it upstream, so can start with a tracking > > > > > > bug > > > > > > on > > > > > > affected packages. > > > > > > > > > > > > > > > > Here's a deal: you can start filing + fixing them. > > > > > > > > > > > > > The [tracker] is already started, it was determined to add QA > > > > warning > > > > with info on filing upstream bugs in [bug 426262] and the > > > > proper > > > > solution is again iterated in [bug 546614], so its not like > > > > this is > > > > a > > > > new approach that is being suggested, but sure, we should all > > > > file > > > > bugs > > > > when we encounter them. > > > > > > > > References: > > > > [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632 > > > > > > > > [bug 426262] > > > > https://bugs.gentoo.org/show_bug.cgi?id=426262 > > > > > > > > [bug 546614] > > > > https://bugs.gentoo.org/show_bug.cgi?id=546614 > > > > > > It seems that the proper fix to this, even for a package that > > > won't > > > do > > > the fix upstream is to use WANT_AUTOCONF in the ebuild to force > > > the > > > version of autoconf you need. > > > > No. It appears you don't know how WANT_AUTOCONF works. > > > From the eclass: > > # @ECLASS-VARIABLE: WANT_AUTOCONF > # @DESCRIPTION: > # The major version of autoconf your package needs > > That leads me to believe that you can set WANT_AUTOCONF="someversion" > in your ebuild and your package will use that version of autoconf. > > If that's wrong, it needs to be fixed and that's a different bug > entirely, but it doesn't change my position on adding this particular > change to autotools.eclass. It is the major version, as documented. Yes, it could specify what these valid versions currently are, as they really are: none 2.1 2.5 latest Currently latest equals 2.5 and is the default. In practice, none means not to add an autoconf atom to DEPEND (even with the default AUTOTOOLS_AUTO_DEPEND=yes) - if ebuild/eclass inheriting autotools.eclass handles its own exact autoconf depend atom (eautoconf will get called in eautoreconf regardless). Only main tree consumer of this appears to be gtk-sharp-module.eclass that adds its own autoconf/automake atoms when needed, because eautoreconf is conditional by variables used by that eclass and it needed autoconf 2.61 or newer, not just 2.59. 2.1 means autoconf:2.1 2.5 and latest currently means >=autoconf-2.59 Patches welcome to documentation, I suppose. It is usually a bad sign if you need to change it away from latest for some reason in the ebuild and ideally they'd all be the default (latest). There was no configure.ac before autoconf-2.50, only configure.in, and thus a warning doesn't make sense. The real warning here is the need for WANT_AUTOCONF=2.1 HTH, Mart ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac 2017-06-11 20:02 ` Mart Raudsepp @ 2017-09-21 14:14 ` Ian Stakenvicius 0 siblings, 0 replies; 15+ messages in thread From: Ian Stakenvicius @ 2017-09-21 14:14 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 3809 bytes --] On 11/06/17 04:02 PM, Mart Raudsepp wrote: > Ühel kenal päeval, P, 11.06.2017 kell 13:08, kirjutas William Hubbs: >> On Sun, Jun 11, 2017 at 07:14:52PM +0300, Mart Raudsepp wrote: >>> Ühel kenal päeval, P, 11.06.2017 kell 11:12, kirjutas William >>> Hubbs: >>>> On Sun, Jun 11, 2017 at 05:35:53PM +0200, Kristian Fiskerstrand >>>> wrote: >>>>> On 06/11/2017 05:24 PM, David Seifert wrote: >>>>>>> We can always patch the eclass at that point if that is >>>>>>> still a >>>>>>> big >>>>>>> concern, but I fundamentally agree with William on this, >>>>>>> starting >>>>>>> point >>>>>>> should be fixing it upstream, so can start with a tracking >>>>>>> bug >>>>>>> on >>>>>>> affected packages. >>>>>>> >>>>>> >>>>>> Here's a deal: you can start filing + fixing them. >>>>>> >>>>> >>>>> The [tracker] is already started, it was determined to add QA >>>>> warning >>>>> with info on filing upstream bugs in [bug 426262] and the >>>>> proper >>>>> solution is again iterated in [bug 546614], so its not like >>>>> this is >>>>> a >>>>> new approach that is being suggested, but sure, we should all >>>>> file >>>>> bugs >>>>> when we encounter them. >>>>> >>>>> References: >>>>> [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632 >>>>> >>>>> [bug 426262] >>>>> https://bugs.gentoo.org/show_bug.cgi?id=426262 >>>>> >>>>> [bug 546614] >>>>> https://bugs.gentoo.org/show_bug.cgi?id=546614 >>>> >>>> It seems that the proper fix to this, even for a package that >>>> won't >>>> do >>>> the fix upstream is to use WANT_AUTOCONF in the ebuild to force >>>> the >>>> version of autoconf you need. >>> >>> No. It appears you don't know how WANT_AUTOCONF works. >> >> >> From the eclass: >> >> # @ECLASS-VARIABLE: WANT_AUTOCONF >> # @DESCRIPTION: >> # The major version of autoconf your package needs >> >> That leads me to believe that you can set WANT_AUTOCONF="someversion" >> in your ebuild and your package will use that version of autoconf. >> >> If that's wrong, it needs to be fixed and that's a different bug >> entirely, but it doesn't change my position on adding this particular >> change to autotools.eclass. > > It is the major version, as documented. Yes, it could specify what > these valid versions currently are, as they really are: > > none > 2.1 > 2.5 > latest > > Currently latest equals 2.5 and is the default. > > In practice, none means not to add an autoconf atom to DEPEND (even > with the default AUTOTOOLS_AUTO_DEPEND=yes) - if ebuild/eclass > inheriting autotools.eclass handles its own exact autoconf depend atom > (eautoconf will get called in eautoreconf regardless). Only main tree > consumer of this appears to be gtk-sharp-module.eclass that adds its > own autoconf/automake atoms when needed, because eautoreconf is > conditional by variables used by that eclass and it needed autoconf > 2.61 or newer, not just 2.59. > > 2.1 means autoconf:2.1 > > 2.5 and latest currently means >=autoconf-2.59 > > Patches welcome to documentation, I suppose. > > > It is usually a bad sign if you need to change it away from latest for > some reason in the ebuild and ideally they'd all be the default > (latest). > > There was no configure.ac before autoconf-2.50, only configure.in, and > thus a warning doesn't make sense. The real warning here is the need > for WANT_AUTOCONF=2.1 > I'm not seeing the issue with what William's suggesting -- if the configure.in is non-trivial to just rename in the ebuild, then setting WANT_AUTOCONF=2.1 would seem to me to be the correct course of action. If there's a package that has a configure.in but also needs autoconf:2.5, well, that seems messed up and likely should be fixed in the ebuild (or upstream) too. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 248 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2017-09-21 14:14 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-06-10 11:28 [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac Jeroen Roovers 2017-06-10 12:04 ` Sergei Trofimovich 2017-06-11 15:00 ` William Hubbs 2017-06-11 15:07 ` Mart Raudsepp 2017-06-11 15:12 ` Kristian Fiskerstrand 2017-06-11 15:17 ` Mart Raudsepp 2017-06-11 15:20 ` Kristian Fiskerstrand 2017-06-11 15:36 ` Alexis Ballier 2017-06-11 15:24 ` David Seifert 2017-06-11 15:35 ` Kristian Fiskerstrand 2017-06-11 16:12 ` William Hubbs 2017-06-11 16:14 ` Mart Raudsepp 2017-06-11 18:08 ` William Hubbs 2017-06-11 20:02 ` Mart Raudsepp 2017-09-21 14:14 ` Ian Stakenvicius
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox