RFR: JDK-8170632 Stop modifying VERSION_OPT for adhoc builds on reconfigure
erik.joelsson at oracle.com
Fri Dec 2 09:10:58 UTC 2016
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.
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
>> 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
>>> --- a/common/autoconf/jdk-version.m4
>>> +++ b/common/autoconf/jdk-version.m4
>>> @@ -160,11 +160,10 @@
>>> 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"
More information about the build-dev