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
quo.
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
requirement.
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
for fontconfig.
/Magnus
On Thu, Jan 18, 2018 at 6:14 PM, David Holmes <david.hol...@oracle.com
<mailto: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
<https://bugs.openjdk.java.net/browse/JDK-8195689>
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8195689-remove-generated-configure/webrev.01
<http://cr.openjdk.java.net/%7Eihse/JDK-8195689-remove-generated-configure/webrev.01>
/Magnus
