RFR: JDK-8170632 Stop modifying VERSION_OPT for adhoc builds on reconfigure

[Erik Joelsson]

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
>>
>