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

Martin Buchholz martinrb at google.com
Fri Jan 19 21:41:09 UTC 2018


Alright folks, you've convinced me.

The "builder interface" is the same "bash configure && make"
(aside: having configure be non-executable is super-annoying, because it
changes an interface burned into my fingers)
and yes, users already have to install many dependencies.
I was thinking you would force users to run some other command like
autoconf; that was the path I recall taken by some other projects.

On debian-based systems, there's "sudo apt-get build-dep openjdk-N" for
some N close to whatever you're actually building.



On Thu, Jan 18, 2018 at 11:49 PM, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

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


More information about the build-dev mailing list