RFR: JDK-8195689 Remove generated-configure.sh and instead use autoconf

[Erik Helin]

On 01/19/2018 07:18 AM, Martin Buchholz wrote:
> Differing projects have come to different conclusions about whether to
> include a generated configure.
> 
> But the standard seems to be to include one. The mantra is: "./configure &&
> make" without an autoconf step.

And this is still the mantra (except we don't have an executable 
configure file in the repo so you have to run `bash configure && make`). 
The only thing we are discussing is whether the script "configure" 
should depend on the program "autoconf" or not.

If I'm downloading a .tar.gz source code bundle of a project (like the 
ones usually generated via `make dist`), then it seems more common that 
"configure" will not depend on autoconf. However, if I'm cloning a 
project from source, then I'm used to having autoconf being run for me 
(or sometimes having to run it myself).

> The number of people building openjdk is
> much larger than the number of people patching configure.  So I agree with
> David that we should stick with the status quo.

I disagree, I don't think depending on autoconf will make it harder to 
build OpenJDK. Remember that the build steps are still:

$ bash configure
$ make

the only difference now is that configure will use autoconf to first 
generate .build/generated-configure.sh. As noted in the documentation, 
installing autoconf is trivial on essentially any system today (the 
configure script will also provide a useful help message for your 
platform if you are missing autoconf).

So for me, this patch gets +1. I'll leave the actual Makefile changes 
and details for Erik J to review though ;)

Thanks,
Erik

> On Thu, Jan 18, 2018 at 6:14 PM, David Holmes <david.holmes at oracle.com>
> wrote:
> 
>> On 18/01/2018 11:28 PM, Magnus Ihse Bursie wrote:
>>
>>> Currently, we require all developers who modify the configure script to
>>> run autoconf locally, to update the generated-configure.sh script, which is
>>> then checked in. This is the only instance of checked in "compiled" code in
>>> OpenJDK, and this has brought along several problems:
>>>
>>> * Only a specific version of autoconf, 2.69, can be used, to avoid large
>>> code changes in the generated file. Unfortunately, Ubuntu ships a version
>>> of autoconf that claims to be 2.69 but is actually heavily patched. This
>>> requires all Ubuntu users to compiler their own autoconf from source.
>>>
>>> * The Oracle JDK closed sources has a closed version that needs to be
>>> updated. In practice, this has meant that all non-Oracle developers, need
>>> an Oracle sponsor for patches modifying the configure script.
>>>
>>> * If the configure script is not properly updated, the build will fail.
>>> The same happens on the Oracle side if the closed version is not in sync
>>> with the open version. It is easy to miss re-generating the script after
>>> the last fix of a typo in the comments in an .m4 file...
>>>
>>> * Merging between two changes containing configure modifications is
>>> almost impossible. In practice, the entire generated-configure.sh needs to
>>> be thrown away and regenerated.
>>>
>>> The entire benefit of having the file in the repo is to save first-time
>>> developers the hassle of installing autoconf. On most platforms, this is a
>>> no-brainer (like "apt install autoconf"), and the requirement is similar to
>>> other open source projects using autoconf and "./configure". It's just not
>>> worth it.
>>>
>>
>> I'm not convinced just by you saying it is so - sorry. This seems to make
>> an already complex build process even more complex for every single person
>> who wants to build OpenJDK, for the benefit of a handful of people who may
>> want to modify configure options and whom already work closely with the
>> build team and so there's really little hardship in getting a sponsor, or
>> just someone with access to autoconf.
>>
>> It introduces a new point of failure in the build for everyone.
>>
>> Has this been beta-tested with external contributors? I'd be happier
>> knowing we've put this through its paces with people developing on a wide
>> range of platforms, before making it the default.
>>
>> Have the devkits been updated so I can try this out myself?
>>
>> Thanks,
>> David
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8195689
>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8195689-remove-generate
>>> d-configure/webrev.01
>>>
>>
>>
>>> /Magnus
>>>
>>