Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 426262 - autotools eclasses should rename configure.in to configure.ac internally (automake-1.14 compatibility)
Summary: autotools eclasses should rename configure.in to configure.ac internally (aut...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords: PATCH, PullRequest
: 468720 546614 613860 (view as bug list)
Depends on: configure.in
Blocks:
  Show dependency tree
 
Reported: 2012-07-12 05:52 UTC by Justin Lecher (RETIRED)
Modified: 2023-05-29 07:57 UTC (History)
14 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
426262-autotools.eclass-deprecated-configure.in.patch (426262-autotools.eclass-deprecated-configure.in.patch,1018 bytes, patch)
2017-06-10 11:29 UTC, Jeroen Roovers (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Lecher (RETIRED) gentoo-dev 2012-07-12 05:52:40 UTC
If we start now, to rename configure.in to configure.ac before eautoreconf we will avoid lots of breakages due to the deprecation of .in in automake-1.13.
What du you think?
Comment 1 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2012-07-12 07:31:40 UTC
(In reply to comment #0)
> If we start now, to rename configure.in to configure.ac before eautoreconf
> we will avoid lots of breakages due to the deprecation of .in in
> automake-1.13.
> What du you think?

Isn't that more like pretending they aren't broken? Well, it would help the old versions on which we run eautoreconf but then i'm not sure if we shouldn't do autoreconf with the older automake version.
Comment 2 Justin Lecher (RETIRED) gentoo-dev 2012-07-12 07:46:08 UTC
As far as I understand from what is written, it is just a name deprecation. So simply renaming it, fixes the issue.
Comment 3 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-07-12 10:23:33 UTC
I think we can start with having it throw a warning first, then we can move on..
Comment 4 SpanKY gentoo-dev 2012-07-15 22:43:41 UTC
if the package doesn't work with automake-1.13, then it should be setting WANT_AUTOMAKE=1.12 in the ebuild, or the package itself should be doing the compatible fixes if they can't get upstream updated
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2012-07-16 06:55:30 UTC
(In reply to comment #3)
> I think we can start with having it throw a warning first, then we can move
> on..

I personally think a warning in portage would be better than in one the eclasses. autotools-utils can do it but autotools would only print it if eautoreconf is done already.

Possibly, we could embed the check into econf, with a nice QA warning. Zac, what do you think?
Comment 6 Zac Medico gentoo-dev 2012-07-16 07:52:14 UTC
Yeah, a warning in portage sounds good.
Comment 7 Justin Lecher (RETIRED) gentoo-dev 2012-07-17 07:29:53 UTC
I am still thinking the autotools.eclass is the better place. .in vs. .ac only matters in case eautoreconf is called. So why don't we only warn in this case?
Comment 8 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2012-07-17 07:37:37 UTC
(In reply to comment #7)
> I am still thinking the autotools.eclass is the better place. .in vs. .ac
> only matters in case eautoreconf is called. So why don't we only warn in
> this case?

Because then a random package will want to apply a single patch and add an eautoreconf, and take your guess..
Comment 9 Diego Elio Pettenò (RETIRED) gentoo-dev 2012-07-17 11:33:00 UTC
And _then_ they'll receive the warning, so the developer can inform upstream.
And _when_ automake 1.13 will be out, if WANT_AUTOMAKE is not set to older version, autotools.eclass will warn _and_ rename.

I agree with Justin, autotools.eclass is the one that should do the work, not the PM.
Comment 10 Diego Elio Pettenò (RETIRED) gentoo-dev 2013-01-13 14:34:23 UTC
This has been moved in on .14 for failure.
Comment 11 SpanKY gentoo-dev 2013-04-27 17:19:23 UTC
(In reply to comment #5)

i don't think checking in econf makes sense.  if i have a package that never runs autotools (because the generated ones are perfectly fine), i'm not going to care about configure.{in,ac}.  in fact, trying to "fix" that warning is only going to slow things down.
Comment 12 Justin Lecher (RETIRED) gentoo-dev 2013-05-06 07:42:14 UTC
*** Bug 468720 has been marked as a duplicate of this bug. ***
Comment 13 Justin Lecher (RETIRED) gentoo-dev 2013-05-06 07:44:06 UTC
Could we please get a QA warning when autotools.eclass functions act on configure.in? the bad autotools release is coming closer and we should start to prepare the tree.
Comment 14 SpanKY gentoo-dev 2014-11-15 05:10:46 UTC
(In reply to Justin Lecher from comment #13)

i've added a eqawarn now:
http://sources.gentoo.org/eclass/autotools.eclass?r1=1.165&r2=1.166

let's see how it shakes out in the tree
Comment 15 Jeroen Roovers (RETIRED) gentoo-dev 2014-11-25 08:26:22 UTC
*** Bug 530478 has been marked as a duplicate of this bug. ***
Comment 16 Michael Mol 2014-11-25 13:17:21 UTC
OK, I'm confused.  SpanKY's patch led me to file #530478, which got marked as a duplicate of this one. But this one was marked RESOLVED/FIXED already, even though my filing is an issue caused by the commit in question.

How is this going to get resolved if everything new gets directed toward a bug that's already marked RESOLVED/FIXED?
Comment 17 Jeroen Roovers (RETIRED) gentoo-dev 2014-11-25 20:27:57 UTC
*** Bug 530478 has been marked as a duplicate of this bug. ***
Comment 18 Pacho Ramos gentoo-dev 2014-11-26 14:45:42 UTC
@base-system, have you think in adding the moving to eautoreconf directly? Otherwise, we will need to add the "mv configure.in configure.ac || die" to really a lot of ebuilds (I have already needed to fix it myself on them in some ebuilds I have been touching and that even without running a tinderbox test over the big amount of packages that didn't get any update for ages and will likely be broken too :/)
Comment 19 Michael Mol 2014-11-26 15:14:28 UTC
A note...if you do this in a general way, you should probably have a "QA notice, this package is using configure.in. Do not file a bug report, but file upstream", so people know to let upstream know.
Comment 20 Roger 2015-01-30 16:27:43 UTC
From what I hear, configure.in was used in versions before 2001.  Looking at the home page repository for autoconf, autoconf-2.50 was released in 2001.  Since autoconf-2.13 is still within Portage with all other Portage autoconf versions being newer, our EBuild script fixes should contain a check in the case autoconf-2.13 is ever used?

ie:

if AUTOCONF_VERSION > 2.13 then
  mv configure.in configure.ac
fi


Just searching or grepping through the Portage tree, I don't think I see any packages currently explicitly calling for autoconf-2.13, but this still could occur.  Some EBuilds called for earlier autoconf versions, such as autoconf-2.5.

Reference:
"...could be named configure.in. It is the name used in older version (before 2001) of Autoconf."
http://developer.gnome.org/anjuta-build-tutorial/stable/create-autotools.html.en
Comment 21 Jeroen Roovers (RETIRED) gentoo-dev 2017-03-26 11:48:51 UTC
*** Bug 613860 has been marked as a duplicate of this bug. ***
Comment 22 Chris Henhawke 2017-03-26 15:09:10 UTC
Not to step on anyone's toes, but I was CCed to this bug when a bug I filed for a specific package with this bug was closed as a duplicate.  There are still many packages which use the old scheme, and IMHO, this message needs to be removed or the packages need to be updated.  Closing bugs before package maintainers can resolve the problem does not help things.
Comment 23 Mike Gilbert gentoo-dev 2017-03-26 18:36:34 UTC
Right. Given that the resolution to this bug was to output a warning message, marking bugs as duplicates is strange.

jer: Why was this bug re-opened?
Comment 24 Jeroen Roovers (RETIRED) gentoo-dev 2017-03-26 18:57:51 UTC
(In reply to Mike Gilbert from comment #23)
> Right. Given that the resolution to this bug was to output a warning
> message, marking bugs as duplicates is strange.

And what should we do with those warnings? Add a `mv' to every ebuild instead of fixing it for everyone in autotools.eclass?

> jer: Why was this bug re-opened?

Because "autotools/autotools-utils eclasses should rename configure.in to configure.ac internally" is not the same as "warn about configure.in".
Comment 25 Mike Gilbert gentoo-dev 2017-03-26 19:17:10 UTC
(In reply to Jeroen Roovers from comment #24)
> (In reply to Mike Gilbert from comment #23)
> > Right. Given that the resolution to this bug was to output a warning
> > message, marking bugs as duplicates is strange.
> 
> And what should we do with those warnings? Add a `mv' to every ebuild
> instead of fixing it for everyone in autotools.eclass?

Yes. It's a bug in upstream sources; submit a patch upstream, and add a workaround in your ebuild.

> > jer: Why was this bug re-opened?
> 
> Because "autotools/autotools-utils eclasses should rename configure.in to
> configure.ac internally" is not the same as "warn about configure.in".

At least one of the maintainers decided not to implement the proposed change. If you want to be picky, change the resolution to WONTFIX instead.
Comment 26 Jeroen Roovers (RETIRED) gentoo-dev 2017-03-26 19:53:41 UTC
*** Bug 613860 has been marked as a duplicate of this bug. ***
Comment 27 Jeroen Roovers (RETIRED) gentoo-dev 2017-03-26 20:15:21 UTC
(In reply to Mike Gilbert from comment #25)
> > And what should we do with those warnings? Add a `mv' to every ebuild
> > instead of fixing it for everyone in autotools.eclass?
> 
> Yes. It's a bug in upstream sources; submit a patch upstream, and add a
> workaround in your ebuild.

Ebuild? Singular?

> > > jer: Why was this bug re-opened?
> > 
> > Because "autotools/autotools-utils eclasses should rename configure.in to
> > configure.ac internally" is not the same as "warn about configure.in".
> 
> At least one of the maintainers decided not to implement the proposed
> change. If you want to be picky, change the resolution to WONTFIX instead.

Bug #530632 should be blocked by hundreds if not thousands of bugs but nobody cared. On the other hand, fixing this in autotools.eclass is trivial.
Comment 28 Chris Henhawke 2017-03-27 04:00:16 UTC
Since 613860 was closed again without the package being fixed, I will not be filing any further bugs on this issue.  I only have limited time to devote to contributing to OSS, and I do not have the time to go to every upstream package maintainer and ask them to rename their files.  

I was hoping that our own package maintainers would be able to do this for me, but that appears not to be the case.  My recommendation in this case would then be to rename the files in the background and not print a message at all.

607686 and 606754 can also be closed if we're just going to ignore these.
Comment 29 Mike Gilbert gentoo-dev 2017-03-27 14:07:35 UTC
(In reply to Jeroen Roovers from comment #27)

Maybe you could send a patch for review? Someone needs to push this forward, or the issue will remain unresolved.
Comment 30 Jeroen Roovers (RETIRED) gentoo-dev 2017-06-10 11:29:11 UTC
Created attachment 475898 [details, diff]
426262-autotools.eclass-deprecated-configure.in.patch

Sent to gentoo-dev@
Comment 31 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-03-28 04:17:42 UTC
Let's do this as an EAPI 8 change to force people to check it actually works, in case of strange edge cases.
Comment 32 Larry the Git Cow gentoo-dev 2021-04-11 21:00:33 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fe3f65790fabb6e98d0b851d3013714c7706eccc

commit fe3f65790fabb6e98d0b851d3013714c7706eccc
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-04-01 00:00:39 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-04-11 20:59:55 +0000

    autotools.eclass: rename configure.in to configure.ac on new EAPIs
    
    automake is eventually going to fail when it detects configure.in.
    
    Don't do this immediately - instead only on new EAPIs to avoid
    breaking existing ebuilds.
    
    Bug: https://bugs.gentoo.org/426262
    Signed-off-by: Sam James <sam@gentoo.org>

 eclass/autotools.eclass | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)
Comment 33 Larry the Git Cow gentoo-dev 2021-07-10 21:41:08 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ff7fb4695d7656feb7b793cd897882b7d49342d6

commit ff7fb4695d7656feb7b793cd897882b7d49342d6
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-07-10 15:12:16 +0000
Commit:     Lars Wendler <polynomial-c@gentoo.org>
CommitDate: 2021-07-10 21:41:02 +0000

    autotools.eclass: rename configure.in to configure.ac on new EAPIs
    
    automake is "eventually" going to fail when it detects configure.in.
    
    Don't do this immediately - instead only on new EAPIs to avoid
    breaking existing ebuilds.
    
    We give an eqawarn (which is triggered by e.g. PORTAGE_ELOG_CLASSES="qa" and
    is opt-in) for maintainers to upstream these where possible, but this isn't
    always the case for software ehich otherwise works but is unmaintained upstream.
    
    Bug: https://bugs.gentoo.org/426262
    Signed-off-by: Sam James <sam@gentoo.org>
    Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>

 eclass/autotools.eclass | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)
Comment 34 Nikita Zlobin 2021-12-27 12:50:01 UTC
I got case when simple file rename is not enough:
https://github.com/GModal/raton

It required at least this replacement to get configure not broken:
sed -i 's/configure.in/configure.ac/g' configure.in 

Although autogen.sh also has commands referring it directly (which is in turn referred from top level Makefile.am), above was enough for ebuild.
Comment 35 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-01-18 17:06:49 UTC
(In reply to Nikita Zlobin from comment #34)
> I got case when simple file rename is not enough:
> https://github.com/GModal/raton
> 
> It required at least this replacement to get configure not broken:
> sed -i 's/configure.in/configure.ac/g' configure.in 
> 
> Although autogen.sh also has commands referring it directly (which is in
> turn referred from top level Makefile.am), above was enough for ebuild.

I think that's interesting although I'm not sure if that's a reason to change the existing logic.
Comment 36 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-01-24 23:36:27 UTC
*** Bug 546614 has been marked as a duplicate of this bug. ***
Comment 37 Larry the Git Cow gentoo-dev 2022-04-27 13:19:05 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=15bc4ddeb0d78cf15632d7d9247532f295943602

commit 15bc4ddeb0d78cf15632d7d9247532f295943602
Author:     Huang Rui <vowstar@gmail.com>
AuthorDate: 2022-04-25 11:04:38 +0000
Commit:     Joonas Niilola <juippis@gentoo.org>
CommitDate: 2022-04-27 13:18:57 +0000

    sci-electronics/iverilog: backport fix compile bug
    
    EAPI: update EAPI 7 -> 8
    fix parse.cc fatal error
    fix calls nm directly
    fix can't find configure.in
    fix depend on sys-libs/readline:=
    
    Bug: https://bugs.gentoo.org/721022
    Bug: https://bugs.gentoo.org/734760
    Bug: https://bugs.gentoo.org/426262
    Closes: https://bugs.gentoo.org/731906
    Closes: https://bugs.gentoo.org/730096
    Signed-off-by: Huang Rui <vowstar@gmail.com>
    Closes: https://github.com/gentoo/gentoo/pull/25191
    Signed-off-by: Joonas Niilola <juippis@gentoo.org>

 .../iverilog/files/iverilog-10.3-call-nm.patch     | 67 +++++++++++++++
 .../files/iverilog-10.3-configure-ac.patch         | 12 +++
 .../files/iverilog-10.3-gen-bison-header.patch     | 97 ++++++++++++++++++++++
 .../files/iverilog-10.3-override-var.patch         | 12 +++
 sci-electronics/iverilog/iverilog-10.3.ebuild      | 23 +++--
 5 files changed, 202 insertions(+), 9 deletions(-)
Comment 38 Pacho Ramos gentoo-dev 2022-12-24 16:03:57 UTC
(In reply to Larry the Git Cow from comment #33)
[...]     
>     We give an eqawarn (which is triggered by e.g. PORTAGE_ELOG_CLASSES="qa"
> and
>     is opt-in) for maintainers to upstream these where possible, but this
> isn't
>     always the case for software ehich otherwise works but is unmaintained
> upstream.
>     
>     Bug: https://bugs.gentoo.org/426262
>     Signed-off-by: Sam James <sam@gentoo.org>
>     Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>
> 
>  eclass/autotools.eclass | 17 ++++++++++++++---
>  1 file changed, 14 insertions(+), 3 deletions(-)

Hello

Is there a way to skip the QA warning without disabling all the other QA checks? As with eapi8 the renaming is done automatically, people have started to drop the manual renaming but, as a consequence, we start to get this useless warning more and more:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fc57dad5a13a2bc2d5c7d6e08a5e0adc207982ff

Useless because it usually affects to software that is not actively maintained upstream and, then, we will keep getting this warning logged even if we cannot do much more than the renaming to fix it :/

Personally I would downgrade it to einfo... but, if you don't want, maybe the eclass could rely on a QA_CONFIGUREIN variable to ignore this kind of issues (as currently dont for ignoring other QA warnings)

Thanks a lot
Thanks
Comment 39 Mike Gilbert gentoo-dev 2022-12-25 02:58:50 UTC
(In reply to Pacho Ramos from comment #38)
> Useless because it usually affects to software that is not actively
> maintained upstream and, then, we will keep getting this warning logged even
> if we cannot do much more than the renaming to fix it :/

In such cases, the ebuild author can/should silence the warning by renaming the file before calling eautoreconf.

I think the portion of fc57dad5a13a2bc2d5c7d6e08a5e0adc207982ff which removes the renaming should be reverted.
Comment 40 Ionen Wolkens gentoo-dev 2022-12-25 05:38:06 UTC
(In reply to Mike Gilbert from comment #39)
> (In reply to Pacho Ramos from comment #38)
> > Useless because it usually affects to software that is not actively
> > maintained upstream and, then, we will keep getting this warning logged even
> > if we cannot do much more than the renaming to fix it :/
> 
> In such cases, the ebuild author can/should silence the warning by renaming
> the file before calling eautoreconf.
> 
> I think the portion of fc57dad5a13a2bc2d5c7d6e08a5e0adc207982ff which
> removes the renaming should be reverted.
I don't agree, packages still using a configure.in are nearly /all/ dead nowadays, so we would be putting this in roughly every ebuilds still using it under those terms. 

The eclass doing it allows to simplify ebuilds and it's what's was done there, there'd be almost no point to this move existing in the eclass otherwise.

Could instead argue that the eclass still giving a qa warning doesn't mean much nowadays, given little hope to report/change for any upstreams at this point.
Comment 41 Ionen Wolkens gentoo-dev 2022-12-25 05:40:08 UTC
(In reply to Ionen Wolkens from comment #40)
> Could instead argue that the eclass still giving a qa warning doesn't mean
> much nowadays, given little hope to report/change for any upstreams at this
> point.
Albeit the information is still semi-useful to know it happened (the move can sometime break the package), could be a einfo instead.
Comment 42 Larry the Git Cow gentoo-dev 2023-05-29 07:57:59 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7835e0d3715d2554e207cb7ed90cf123379acd87

commit 7835e0d3715d2554e207cb7ed90cf123379acd87
Author:     Ulrich Müller <ulm@gentoo.org>
AuthorDate: 2023-05-28 13:12:42 +0000
Commit:     Ulrich Müller <ulm@gentoo.org>
CommitDate: 2023-05-29 07:57:53 +0000

    autotools.eclass: Downgrade eqawarn for renaming configure.in
    
    At this point, almost all upstreams will have switched to configure.ac.
    Therefore, configure.in is most likely an indication of an inactive
    upstream, and there is no reasonable way for the ebuild maintainer to
    silence the warning (other than the ebuild renaming the file).
    
    Keep the message as einfo, so there is still an indication that the file
    was renamed.
    
    Bug: https://bugs.gentoo.org/426262
    Reviewed-by: Sam James <sam@gentoo.org>
    Reviewed-by: Pacho Ramos <pacho@gentoo.org>
    Signed-off-by: Ulrich Müller <ulm@gentoo.org>

 eclass/autotools.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)