The generated-configure.sh script is dead, long live autoconf!
erik.joelsson at oracle.com
Mon Feb 5 22:14:49 UTC 2018
In that change I bumped the number from 2.61 to 2.67. The original 2.61
was put there by Fredrik very early in the build-infra conversion and I
don't know where that came from. The main reason for us to pick just one
version was because we wanted to avoid large differences in the
committed generated file. Since we are no longer committing the file, I
don't see a good reason to enforce a particular version, but we also
should not change this number until someone has verified that a
particular version works reasonably well.
It should also be noted that installing autoconf from src is trivially
simple. The build has very few prerequisites and takes seconds to
complete. I've never failed on any of the platforms I've tried it on
over the years.
On 2018-02-05 12:14, Magnus Ihse Bursie wrote:
> On 2018-02-05 21:05, Magnus Ihse Bursie wrote:
>> Let's move this discussion to build-dev instead of jdk-dev.
>> On 2018-02-05 17:30, Thomas Stüfe wrote:
>>> Hi Magnus,
>>> On Mon, Feb 5, 2018 at 9:21 AM, Magnus Ihse Bursie
>>> <magnus.ihse.bursie at oracle.com
>>> <mailto:magnus.ihse.bursie at oracle.com>> wrote:
>>> <snip> With the new solution, the exact version of autoconf does
>>> not matter. <snip>
>>> It seems to matter. I now get:
>>> Using autoconf at /usr/bin/autoconf [autoconf (GNU Autoconf) 2.63]
>>> stdin:33: error: Autoconf version 2.69 or higher is required
>>> stdin:33: the top level
>>> autom4te: /usr/bin/m4 failed with exit status: 63
>>> Do we actually need this strict check for the autoconf version? Is
>>> there a way to disable the check and retry with my old version?
>> The check is enforced by
>> in the top of make/autoconf/configure.ac.
>> You could try removing it and see what happens. In the "best" case
>> you'll get an error message when autoconf tries to generate the file,
>> then we know for certain that it does not work. :-) Otherwise, you'll
>> have to test the generated configure file more thoroughly to ensure
>> that it really works.
>> I'm quite certain that older versions (and believe me, everything
>> prior to 2.69 is *ancient*) did not work at all, and that was the
>> reason we added that requirement.
> Some code archeology gave me this:
> It seems that we at least supported 2.67 at the time, but we
> executable was not commonly (?) named "autoconf" so we couldn't
> autodetect it. Still can't say about 2.63 though.
>>> I would dislike for this to be a frequent error now - unfortunately,
>>> we have some build environments where getting the latest GNU tools
>>> is more work than just running an installer.
>>> Thanks, Thomas
>>> The build documentation has been updated to reflect this change.
More information about the build-dev