Skip all version checks with autoconf?

[Jeffrey Walton]

I'm catching this error on Fedora 28, x86_64, fully patched:

$ autoreconf -fi
configure.ac:35: error: require Automake 1.16.1, but have 1.15.1
autoreconf: automake failed with exit status: 1

This is a chronic problem with Autotools. Nearly every program that
gets patched has a problem like this. I no longer want to perform
version checks. I waste too much time dicking around with the problems
they cause.

I'm happy to take a break later in the process. I think I have more
hope of fixing the actual problem if it is encountered.

How do I skip all version checks?

Jeff

[Eric Blake]

Post by Jeffrey Walton
$ autoreconf -fi
configure.ac:35: error: require Automake 1.16.1, but have 1.15.1
autoreconf: automake failed with exit status: 1

You'll need to ask whatever project you are trying to build what feature
from automake 1.16 they actually require, or whether they can relax
their autoconf.ac to list a lower version number in their
AM_INIT_AUTOMAKE() invocation.

Post by Jeffrey Walton
This is a chronic problem with Autotools. Nearly every program that
gets patched has a problem like this. I no longer want to perform
version checks. I waste too much time dicking around with the problems
they cause.

It is not autoconf's problem when someone writes a configure.ac that
wrongly claims to use too-new of a version of automake. But if you
don't think the package is actually relying on a feature that only that
newer automake provided, you are welcome to edit configure.ac and change
the AM_INIT_AUTOMAKE() line to list a lower version number, rerun
autoreconf, and see if it completes successfully.

Post by Jeffrey Walton
I'm happy to take a break later in the process. I think I have more
hope of fixing the actual problem if it is encountered.
How do I skip all version checks?

There's no magic environment variable to skip version checks built into
autoreconf, but as with all open source, you are welcome to edit the
source code at fault (the project's configure.ac) to comment out that
project's particular version check.

Or, actually install newer versions of the autotools.

[Jeffrey Walton]

It is not autoconf's problem when someone writes a configure.ac that wrongly
claims to use too-new of a version of automake. But if you don't think the
package is actually relying on a feature that only that newer automake
provided, you are welcome to edit configure.ac and change the
AM_INIT_AUTOMAKE() line to list a lower version number, rerun autoreconf,
and see if it completes successfully.

OK, let's get rid of these useless checks whose only purpose is to
stop someone from accomplishing their task at hand.

sed -i '/AM_INIT_AUTOMAKE/d' configure.ac

And what a surprise:

$ autoreconf -f -i
Can't exec "autopoint": No such file or directory at
/usr/share/autoconf/Autom4te/FileUtils.pm line 345.
autoreconf: failed to run autopoint: No such file or directory

Autotools does everything in its freaking powers to stop someone from
accomplishing their task.

Or, actually install newer versions of the autotools.

Lol... That put milk up my nose. I've tried to install newer versions
and they have never worked right. The admins on the GCC compile farm
tried the same and the shit does not work right. Claiming someone can
upgrade these tools is a joke.

Jeff

[Jeffrey Walton]

Post by Jeffrey Walton

It is not autoconf's problem when someone writes a configure.ac that wrongly
claims to use too-new of a version of automake. But if you don't think the
package is actually relying on a feature that only that newer automake
provided, you are welcome to edit configure.ac and change the
AM_INIT_AUTOMAKE() line to list a lower version number, rerun autoreconf,
and see if it completes successfully.

OK, let's get rid of these useless checks whose only purpose is to
stop someone from accomplishing their task at hand.
sed -i '/AM_INIT_AUTOMAKE/d' configure.ac
$ autoreconf -f -i
Can't exec "autopoint": No such file or directory at
/usr/share/autoconf/Autom4te/FileUtils.pm line 345.
autoreconf: failed to run autopoint: No such file or directory
Autotools does everything in its freaking powers to stop someone from
accomplishing their task.

Or, actually install newer versions of the autotools.

Lol... That put milk up my nose. I've tried to install newer versions
and they have never worked right. The admins on the GCC compile farm
tried the same and the shit does not work right. Claiming someone can
upgrade these tools is a joke.

All version numbers have been changed to 0.00. This is the joke we
have to contend with:

$ autoreconf -f -i
autopoint: *** The AM_GNU_GETTEXT_VERSION declaration in your configure.ac
file requires the infrastructure from gettext-0.00 but
this version
is older. Please upgrade to gettext-0.00 or newer.
autopoint: *** Stop.

How do you get older than the first version of a package???

For the love of Christ, stop it with these useless version numbers.
All they do is stop someone from accomplishing their task. Let the
task fail where it fails if someone is using the feature.

How freaking complicated can a simple 'configure && make && make
install' be made???

[Paul Eggert]

Post by Jeffrey Walton
For the love of Christ, stop it with these useless version numbers.

I've never been a fan of that version-number checking either, but this is no way
to advocate change.

If you want the problem fixed, I suggest that you write a patch to the Autoconf
source code that fixes the problem. The patch should fix the documentation too.
If you don't have the technical expertise to do all that, you can hire someone
who does. In the meantime please bear in mind that this is a volunteer project
and we're stretched thin.

[Basin Ilya]

For some reason the authors like to require the latest autotools version they have. That's wrong. They should require the lowest supported version.

Post by Jeffrey Walton
For the love of Christ, stop it with these useless version numbers.

I've never been a fan of that version-number checking either, but this is no way to advocate change.
If you want the problem fixed, I suggest that you write a patch to the Autoconf source code that fixes the problem. The patch should fix the documentation too. If you don't have the technical expertise to do all that, you can hire someone who does. In the meantime please bear in mind that this is a volunteer project and we're stretched thin.
_______________________________________________
Autoconf mailing list
https://lists.gnu.org/mailman/listinfo/autoconf

[Nicholas Clark]

Not saying this is right or wrong, but as an autoconf user - it can be hard
to know what versions support what features. So if I'm autotoolizing a
package, I would probably require whatever version I had at the time.

Are there any tools out there that will scan a configure.ac/Makefile.am and
tell me what versions are compatibile?

-Nick

Post by Basin Ilya
For some reason the authors like to require the latest autotools version
they have. That's wrong. They should require the lowest supported version.

Post by Paul Eggert

Post by Jeffrey Walton
For the love of Christ, stop it with these useless version numbers.

I've never been a fan of that version-number checking either, but this

is no way to advocate change.

Post by Paul Eggert
If you want the problem fixed, I suggest that you write a patch to the

Autoconf source code that fixes the problem. The patch should fix the
documentation too. If you don't have the technical expertise to do all
that, you can hire someone who does. In the meantime please bear in mind
that this is a volunteer project and we're stretched thin.

Post by Paul Eggert
_______________________________________________
Autoconf mailing list
https://lists.gnu.org/mailman/listinfo/autoconf

_______________________________________________
Autoconf mailing list
https://lists.gnu.org/mailman/listinfo/autoconf

[Basin Ilya]

I have a VM with RHEL 6.8, because that's what our customers build our software on. And when I change anything in configure.ac, I test it there.
Of course, such conservative attitude is unnecessary for open source projects, but supporting four year old autotools looks reasonable.

Post by Nicholas Clark
Not saying this is right or wrong, but as an autoconf user - it can be hard
to know what versions support what features. So if I'm autotoolizing a
package, I would probably require whatever version I had at the time.
Are there any tools out there that will scan a configure.ac/Makefile.am and
tell me what versions are compatibile?
-Nick

Post by Basin Ilya
For some reason the authors like to require the latest autotools version
they have. That's wrong. They should require the lowest supported version.

Post by Paul Eggert

Post by Jeffrey Walton
For the love of Christ, stop it with these useless version numbers.

I've never been a fan of that version-number checking either, but this

is no way to advocate change.

Post by Paul Eggert
If you want the problem fixed, I suggest that you write a patch to the

Autoconf source code that fixes the problem. The patch should fix the
documentation too. If you don't have the technical expertise to do all
that, you can hire someone who does. In the meantime please bear in mind
that this is a volunteer project and we're stretched thin.

Post by Paul Eggert
_______________________________________________
Autoconf mailing list
https://lists.gnu.org/mailman/listinfo/autoconf

_______________________________________________
Autoconf mailing list
https://lists.gnu.org/mailman/listinfo/autoconf

_______________________________________________
Autoconf mailing list
https://lists.gnu.org/mailman/listinfo/autoconf

[Warren Young]

Post by Basin Ilya
I have a VM with RHEL 6.8, because that's what our customers build our software on. And when I change anything in configure.ac, I test it there.
Of course, such conservative attitude is unnecessary for open source projects, but supporting four year old autotools looks reasonable.

Any open source project should know its audience. I run one where we maintain compatibility with software up to about 10-12 years old, just because it’s that sort of project. Consequently, new releases get tested on a CentOS 5 box, even though that’s “unsupported” by the distro and its upstream.

It sounds like the developers of the software project the OP is currently fighting with don’t understand that they have users not out on the bleeding edge with themselves. He should be getting that message to them, not blaming Autotools.

Version numbers, properly used, are not “useless.” See

https://semver.org/

for one particularly well thought out argument.

Done properly, a good version numbering system lets users make correct inferences about what a given version change means. That’s highly useful.

The trick is getting developers to declare their versioning system’s meanings and to stick to it.

[Marko Lindqvist]

Indeed. When considering addition of a new macro call to configure.ac
it often requires a lot of digging (usually from NEWS) to find out if
using that macro is safe with current minimum autoconf version
requirement. It would be really good if the documentation about macros
would say what version of autoconf introduced them, or made an API
change (such as starting to support additional parameters) to them.

- ML

Post by Nicholas Clark
Not saying this is right or wrong, but as an autoconf user - it can be hard
to know what versions support what features. So if I'm autotoolizing a
package, I would probably require whatever version I had at the time.
Are there any tools out there that will scan a configure.ac/Makefile.am and
tell me what versions are compatibile?
-Nick

Post by Basin Ilya
For some reason the authors like to require the latest autotools version
they have. That's wrong. They should require the lowest supported version.

Post by Paul Eggert

Post by Jeffrey Walton
For the love of Christ, stop it with these useless version numbers.

I've never been a fan of that version-number checking either, but this

is no way to advocate change.

Post by Paul Eggert
If you want the problem fixed, I suggest that you write a patch to the

Autoconf source code that fixes the problem. The patch should fix the
documentation too. If you don't have the technical expertise to do all
that, you can hire someone who does. In the meantime please bear in mind
that this is a volunteer project and we're stretched thin.

Post by Paul Eggert
_______________________________________________
Autoconf mailing list
https://lists.gnu.org/mailman/listinfo/autoconf

_______________________________________________
Autoconf mailing list
https://lists.gnu.org/mailman/listinfo/autoconf

_______________________________________________
Autoconf mailing list
https://lists.gnu.org/mailman/listinfo/autoconf

[Bob Friesenhahn]

Post by Marko Lindqvist
Indeed. When considering addition of a new macro call to configure.ac
it often requires a lot of digging (usually from NEWS) to find out if
using that macro is safe with current minimum autoconf version
requirement. It would be really good if the documentation about macros
would say what version of autoconf introduced them, or made an API
change (such as starting to support additional parameters) to them.

The most recent Autoconf release is quite a long time ago (2012, and
it is 2018 already) so these concerns are a surprise to me.

Why is it so difficult to support a version which has been stable for
6 years already?

Bob

[Keith Marshall]

Post by Bob Friesenhahn

Post by Marko Lindqvist
Indeed. When considering addition of a new macro call to
configure.ac it often requires a lot of digging (usually from
NEWS) to find out if using that macro is safe with current
minimum autoconf version requirement. It would be really good if
the documentation about macros would say what version of autoconf
introduced them, or made an API change (such as starting to
support additional parameters) to them.

The most recent Autoconf release is quite a long time ago (2012,
and it is 2018 already) so these concerns are a surprise to me.
Why is it so difficult to support a version which has been stable
for 6 years already?

It isn't really autoconf's fault, but rather client projects which
misuse the version checking features. For example, when creating a
cross-native GCC-6.3.0 build for MinGW.org, I discovered a bogus
configuration check, which prevented cross-compiling the gnat
libraries; (there was even a comment, IIRC, which suggested that the
maintainer knew that the test was bogus). In consultation with said
maintainer, we came up with a corrected test. I fixed it in the
relevant configure.ac, but when I ran autoreconf, I was advised to
"upgrade" my autoconf to version 2.64 ... I already have 2.69! (And
yes, I do realize that this is GCC going way beyond the restrictions
AC_PREREQ might be expected to impose).

If projects as venerable as GCC can get this so badly wrong, what
chance for the rest? In my case, I ended up manually hacking
configure itself, to achieve the desired correction.

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F

[Eric Blake]

Post by Jeffrey Walton

It is not autoconf's problem when someone writes a configure.ac that wrongly
claims to use too-new of a version of automake. But if you don't think the
package is actually relying on a feature that only that newer automake
provided, you are welcome to edit configure.ac and change the
AM_INIT_AUTOMAKE() line to list a lower version number, rerun autoreconf,
and see if it completes successfully.

OK, let's get rid of these useless checks whose only purpose is to
stop someone from accomplishing their task at hand.
sed -i '/AM_INIT_AUTOMAKE/d' configure.ac

Nope, that's not how you do it. You NEED the AM_INIT_AUTOMAKE() line,
just not necessarily the higher version number requirement within the line.

I'm thinking more along the lines of:

sed -i '/AM_INIT_AUTOMAKE/ s/\b[0-9.]*\b//'

Post by Jeffrey Walton

Or, actually install newer versions of the autotools.

Lol... That put milk up my nose. I've tried to install newer versions
and they have never worked right. The admins on the GCC compile farm
tried the same and the shit does not work right. Claiming someone can
upgrade these tools is a joke.

Insulting the tools and/or the people that are trying to help you
resolve your issues isn't going to resolve the issue.

[Earnie]

Post by Eric Blake

Post by Jeffrey Walton

It is not autoconf's problem when someone writes a configure.ac that wrongly
claims to use too-new of a version of automake.  But if you don't
think the
package is actually relying on a feature that only that newer automake
provided, you are welcome to edit configure.ac and change the
AM_INIT_AUTOMAKE() line to list a lower version number, rerun autoreconf,
and see if it completes successfully.

OK, let's get rid of these useless checks whose only purpose is to
stop someone from accomplishing their task at hand.
      sed -i '/AM_INIT_AUTOMAKE/d' configure.ac

Nope, that's not how you do it. You NEED the AM_INIT_AUTOMAKE() line,
just not necessarily the higher version number requirement within the line.
sed -i '/AM_INIT_AUTOMAKE/ s/\b[0-9.]*\b//'

Wouldn't wrappers like Cygwin uses work? Of course the wrapper requires
you to have every possible version available. Note there is a wrapper
both for autoconf and automake.