Hello Julian,
You are misunderstanding Magnus here. What he means is that we are
compiling the version numbers into Java classes and native libraries
(through generating Java source files with the version information in
them and by setting -D flags when compiling C/C++). Because of this, if
we let the version string dynamically update at make time, we would
always have to recompile those files on incremental builds, which
triggers quite a bit of downstream rebuilding (relinking jibjvm,
recreating jmods and images etc). This makes the incremental build slow
and unwieldy and would be impractical for most developers.
What Magnus is suggesting is that in the final JDK image, we would have
a text file with the version information in it, and every native lib or
Java class in the JDK that currently has this compiled into it, would
instead know how to reference it from this text file.
It's not clear to me if this is a feasible proposal.
/Erik
On 2022-03-04 07:46, Julian Waters wrote:
Hi Magnus,
While looking through the now resolved JDK-8274980
<https://bugs.openjdk.java.net/browse/JDK-8274980> one discussed
possibility in particular caught my eye:
"The one thing remaining now to make me fully happy wrt version numbers, is
if we could stop hard-coding them into files during build, and instead have
interested parties read it from a text file."
By hardcoded files, are you referring to the files generated when configure
is run? In my opinion a separate text file wouldn't be needed if a flag is
set somewhere, and we could instead modify the generated spec.gmk to run
other support scripts to determine VERSION_BUILD if it hasn't been set yet
(ie shifting automated version detection to when make is called by changing
spec.gmk.in to an absolute value if --with-version-opt was passed, and
compile time check otherwise). perhaps by escaping bash variables into make
while it's running. What do you think?
Thanks for your time and I'm really sorry if I'm troubling you on this,
have a great day! :)
best regards,
Julian
