Another possibility is implementing the invariant that configure is generated via autoconf 2.69 by a mercurial commit hook.
On Thu, Jan 18, 2018 at 10:18 PM, Martin Buchholz <marti...@google.com> 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. > > 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 >>> >> >
