RFR: JDK-8195689 Remove generated-configure.sh and instead use autoconf
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Fri Jan 19 07:43:59 UTC 2018
On 2018-01-19 07:18, 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. 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
This patch will not introduce a separate autoconf step. Please see the
updated build readme in my patch. The only difference is an added build
If someone wants to contribute to OpenJDK, installing external
dependencies for the build can hardly be the biggest hurdle. If we
*really* thought that was an issue, then we should start bundling much
more external dependencies. Like freetype, which is a *real* problem for
all Windows users, for instance.
I don't think that's the right way to go, though. And in general, the
direction of OpenJDK for the last few years has been in the opposite
direction: less bundling, more external dependencies. The community has
requested configure arguments for using the system provided versions of
libraries that we also bundle. We've stopped linking statically with
glibc. We've removed bundled source code and introduced a new dependency
> On Thu, Jan 18, 2018 at 6:14 PM, David Holmes <david.holmes at oracle.com
> <mailto: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?
> Bug: https://bugs.openjdk.java.net/browse/JDK-8195689
More information about the build-dev