Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[Ian Stakenvicius]

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.