RFR: JDK-8170632 Stop modifying VERSION_OPT for adhoc builds on reconfigure
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Fri Dec 2 08:33:11 UTC 2016
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*.
>> 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
>> 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