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