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.hol...@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
