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

[Magnus Ihse Bursie]

On 2018-01-19 08:08, Erik Helin wrote:
> 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).
Good point. If we were to start shipping source code bundles, it would 
certainly make sense to include a generated configure script for it. I'm 
all for it. The problem here is that the current model presupposes a 
working, generated configure script for every separate commit.

I'll admit that I was part of introducing this model some five (or 
more?) years ago. I didn't really like it then either, but at that time 
I perceived it to be a quite massive resistance amongst the JDK 
developers (perhaps mostly inside Oracle) for any kind of change in the 
environment, so adding a new build requirement seemed like a huge war 
that was needed to be fought. (Just removing the old build system was 
enough effort...) Nowadays, we're using jib inside Oracle, so a new 
requirement is virtually undetectable by most developers. And for all 
others, it's just an "sudo apt install autoconf" (or brew, or whatever) 
away, in the unlikely case that you're a developer without autoconf 
installed already.

/Magnus
>
>> 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
>>>>
>>>