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:
: 468720 613860 (view as bug list)
Depends on: configure.in
Blocks:
  Show dependency tree
 
Reported: 2012-07-12 05:52 UTC by Justin Lecher
Modified: 2017-12-18 11:12 UTC (History)
11 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
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Lecher 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 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 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 gentoo-dev 2013-05-06 07:42:14 UTC
*** Bug 468720 has been marked as a duplicate of this bug. ***
Comment 13 Justin Lecher 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 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 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 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 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 gentoo-dev 2017-03-26 19:53:41 UTC
*** Bug 613860 has been marked as a duplicate of this bug. ***
Comment 27 Jeroen Roovers 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 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@