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
