Configure "developer mode" [was: Re: RFR: JDK-8217723 Switch ld from bfd to gold on gcc toolchain]

[Magnus Ihse Bursie]

On 2019-01-25 18:15, Martin Buchholz wrote:
> In our own wrappers around configure, we've introduced the concept of
> a "developer mode".  But this thread suggests there are 3 populations
> of users invoking configure:
>
> 1. release engineers
> 2. hotspot developers
> 3. java library developers
>
> Category 1 doesn't care about edit-compile-debug cycle - they just
> want to build a reliable high-performance jdk without pitfalls.  This
> is the VAST MAJORITY of users, for whom we should design defaults in
> configure.
> Category 2 wants debug info and maybe incremental linking.  They might
> cheat and rebuild only libjvm.so and drop that one file into a
> previously built jdk as part of their development cycle.
> Category 3 doesn't care about native debug symbols at all
I've been thinking about doing something similar in configure, for quite 
some time. This time I intend to finish it as part of JDK-8217722.

However, my analysis has been somewhat different. Let me try to put it 
in your terms:

1. This sounds not like a "developer" at all, but either something like 
a one-shot hobbyist build, or an automated script on a build farm.

2 and 3 I consider the same. As Phil said, even JDK (as in contrast to 
"hotspot developers") need to tackle native code. And even if they 
don't, because they are blessed with a native-free module, they will not 
be hurt by having the binaries build using incremental linking. They 
will require a quick path to re-building individual modules, and to 
build an image usable for testing. And contrary, hotspot developers are 
not hurt by a fast java compilation path, and they too require a fast 
path to re-building an image used for testing.

I'm also thinking like this:

Category 1 will either be a script, which much likely already has a long 
and complicated configure command line; or it is a one-shot hobbyist 
build, where you are probably already copy-pasting configure options 
from the readme file, or instructions on the Internet.

Category 2/3 will be creating new clones left and right, constantly 
rerunning configure from the command line.

With this in mind, I'm proposing to make the default friendly to 
category 2/3, rather than 1. Scripts can easily be updated; and the 
hobbyist builder will need to bother with an extra argument (or 
possibly, they don't care).

Names are tricky, though. I'm thinking maybe --with-build-mode=, 
--with-defaults or --with-preset. They all carry a slightly different 
meaning. And while category 2/3 has the relatively obvious name 
"develop" (or "developer"), category 1 is harder. Perhaps "release" (but 
that can be misinterpreted as being part of the debug/release 
dichotomy). Maybe somthing like "ci", "system" or "buildfarm" -- but 
while that comes out nicely for the build scripts, it sound odd to the 
hobbyist builder. If I go with --with-preset or --with-defaults, then 
perhaps "build" would be a suitable choice: --with-preset=develop or 
--with-preset=build; has a nice ring to it.

And finally, I'm also thinking about "extending" the latter category 
into a "strict" mode, which is what we try to achieve in our CI builds 
in Oracle. In strict mode, configure would not pick anything up 
automatically from the environment, but instead all prereqs (*possibly* 
excluding basic unix tools, but I'm not even sure about that) would need 
to be pointed out by configure options.

/Magnus