After a bit of offline discussion, I'm hesitantly ok with this, at least
enough to try. I can't deny that it would make my life easier if
reconfigure didn't automatically enforce a full java rebuild.
The release file at the root of linked images does contain a comment
with a timestamp, so there is something to look for if you need to tell
built binaries apart.
/Erik
On 2016-12-02 09:38, Magnus Ihse Bursie wrote:
On 2016-12-02 09:24, Erik Joelsson wrote:
I don't think removing the time stamp is such a good idea. Then there
is nothing in the version string to tell my builds apart.
What kind of builds are you trying to tell apart? Different builds
from the same configuration will right now have the same version
string anyway.
And if you are talking about builds from different mercurial clones,
the version string will still contain the name of the directory.
(That's the only thing really that I use.)
Neither will this affect JPRT, it has it's own logic for specifying
JPRT job names.
This will only show up when running "java -version".
What would you say if I stored an extra file in the exploded-jdk
and/or image directory containing the timestamp of the last build? If
we just want a simple timestamp in a file, it's trivial and instant,
and can be updated at each incremental build. You would need to have
to locate that file manually though, not just running "java -version".
Also, to not mess with release manifests, I'd like to add such a file
to adhoc builds only. (But that would probably be the only place it
matters.)
/Magnus
/Erik
On 2016-12-01 23:39, Magnus Ihse Bursie wrote:
Our current default is to create a version-opt string on the format
'<timestamp>.<username>.<base dir name>' during configure.
The problem with this is that each time the configure script has
change, a reconfigure is triggered. This will create a new
version-opt, and hence a new version string. This in turn will
trigger a rebuild of hotspot and java.base, and that in turn
rebuilds the whole world.
It does not have to be like that. In fact, storing the time stamp of
the last configure, rather than the time stamp of the last build is
rather silly anyhow.
In a perfect world we could just update the version-opt string and
have this resulting in an extremely short rebuild time.
Unfortunately, we do not live in a perfect world, and here it makes
more sense to drop the timestamp.
Note that this only affects adhoc (developer) builds.
Bug: https://bugs.openjdk.java.net/browse/JDK-8170632
Patch inline:
diff --git a/common/autoconf/jdk-version.m4
b/common/autoconf/jdk-version.m4
--- a/common/autoconf/jdk-version.m4
+++ b/common/autoconf/jdk-version.m4
@@ -160,11 +160,10 @@
fi
else
if test "x$NO_DEFAULT_VERSION_PARTS" != xtrue; then
- # Default is to calculate a string like this
<timestamp>.<username>.<base dir name>
- timestamp=`$DATE '+%Y-%m-%d-%H%M%S'`
+ # Default is to calculate a string like this
'adhoc.<username>.<base dir name>'
# Outer [ ] to quote m4.
[ basedirname=`$BASENAME "$TOPDIR" | $TR -d -c
'[a-z][A-Z][0-9].-'` ]
- VERSION_OPT="$timestamp.$USERNAME.$basedirname"
+ VERSION_OPT="adhoc.$USERNAME.$basedirname"
fi
fi
/Magnus
