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

[Magnus Ihse Bursie]

On 2016-12-02 02:47, David Holmes wrote:
> On 2/12/2016 8:39 AM, 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.
>
> Surely after a reconfigure you _have_ to rebuild the world? It even 
> warns you to do a clean after a reconfigure.

Well, it depends. :-)

Not doing a make clean after a reconfigure is like using the *-only 
targets or JDK_FILTER -- it speeds things up, often considerably, but it 
not guaranteed to be correct. But, if you know what you're doing, you 
can get a result that is correct anyway.

We used to be very bad at detecting changes in the spec.gmk during the 
make phase, so if you changed a configuration and just rebuilt without a 
clean, we would end up with a very messy state. Nowadays, we have proper 
dependencies of most (but not all, yet) input variables, so if a new 
configuration changes any values that has relevance for the build, these 
parts should be rebuilt.

Typically, changes to the configuration script could be a small bug fix, 
e.g. the one I'm working with right now, that checks the correct version 
of ccache on macosx. Whenever I push that change, the 
generated-configure.sh will change, and this will cause the make file to 
claim that the current spec.gmk is out of date. (Which is true, because 
it *could* have been a breaking change). So, it will regenerate the 
spec.gmk. But nothing in it will change (unless you're running with a 
broken ccache on macosx), so this *shouldn't* really have to cause any 
rebuilds. And if the spec.gmk *really* didn't change, it wouldn't. But, 
during the reconfigure, we will change the version string. So... *duh*.

/Magnus

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