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
