Re: The generated-configure.sh script is dead, long live autoconf!

2018-02-05 Thread Magnus Ihse Bursie 

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 
mailto:magnus.ihse.bur...@oracle.com>> 
wrote:


 With the new solution, the exact version of autoconf does
not matter. 


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
AC_PREREQ([2.69])

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.


/Magnus



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.

/Magnus

Re: The generated-configure.sh script is dead, long live autoconf!

2018-02-05 Thread Magnus Ihse Bursie 

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 
> wrote:


     With the new solution, the exact version of autoconf does
    not matter. 


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
AC_PREREQ([2.69])

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: 
https://bugs.openjdk.java.net/browse/JDK-8023957


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.




/Magnus



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.

    /Magnus

Re: The generated-configure.sh script is dead, long live autoconf!

2018-02-05 Thread Erik Joelsson 

Hello,

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.


/Erik


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 
> wrote:


     With the new solution, the exact version of autoconf does
    not matter. 


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
AC_PREREQ([2.69])

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: 
https://bugs.openjdk.java.net/browse/JDK-8023957


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.




/Magnus



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.

    /Magnus

Re: The generated-configure.sh script is dead, long live autoconf!

2018-02-06 Thread Thomas Stüfe 
Hi,

On Mon, Feb 5, 2018 at 11:14 PM, Erik Joelsson 
wrote:

> Hello,
>
> 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.
>
>
You are right, maybe adapting to autoconf 2.69 is the cleaner way to go
instead of trying to make the builds run with an older autoconf. As Volker
wrote, this is a step in the right direction; we just have to go through
our platforms and build a more modern autoconf.

Kind Regards, Thomas


> /Erik
>
>
>
> 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.bur...@oracle.com >
 wrote:

  With the new solution, the exact version of autoconf does
 not matter. 


 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
>>> AC_PREREQ([2.69])
>>>
>>> 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: https://bugs.openjdk.java.net/
>> browse/JDK-8023957
>>
>> 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.
>>
>>
>>> /Magnus
>>>
>>>
 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.

 /Magnus



>>>
>>
>

Re: The generated-configure.sh script is dead, long live autoconf!

2018-02-06 Thread dalibor topic 

On 06.02.2018 09:51, Thomas Stüfe wrote:

You are right, maybe adapting to autoconf 2.69 is the cleaner way to go
instead of trying to make the builds run with an older autoconf.

It most likely is.

The older the autoconf is that one requires, the more problematic using 
the OS provided one becomes, as due to the murky past of autotools, OS 
vendors used to patch them quite extensively to try to work around the 
effects of incompatibilities in transitions between 2.13 and 2.50.


The autoconf civil wars took many years to settle down. See 
https://cygwin.com/ml/cygwin-announce/2001/msg00177.html for an example 
of the accidental complexity that the whole thing triggered.


cheers,
dalibor topic
--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

Re: The generated-configure.sh script is dead, long live autoconf!

2018-02-06 Thread Thomas Stüfe 
On Tue, Feb 6, 2018 at 10:36 AM, dalibor topic 
wrote:

> On 06.02.2018 09:51, Thomas Stüfe wrote:
>
>> You are right, maybe adapting to autoconf 2.69 is the cleaner way to go
>> instead of trying to make the builds run with an older autoconf.
>>
> It most likely is.
>
> The older the autoconf is that one requires, the more problematic using
> the OS provided one becomes, as due to the murky past of autotools, OS
> vendors used to patch them quite extensively to try to work around the
> effects of incompatibilities in transitions between 2.13 and 2.50.
>
> The autoconf civil wars took many years to settle down. See
> https://cygwin.com/ml/cygwin-announce/2001/msg00177.html for an example
> of the accidental complexity that the whole thing triggered.
>

Reading through this is quite painful :) Yes, I am convinced now.

..Thomas


>
> cheers,
> dalibor topic
> --
>  Dalibor Topic | Principal Product Manager
> Phone: +494089091214  | Mobile: +491737185961
> 
>
> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Ham
> 
> burg
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-8
> 0992
> München
> Registergericht: Amtsgericht München, HRA 95603
>
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>
>  Oracle is committed to developing
> practices and products that help protect the environment
>