8007097: (profiles) Build needs test to ensure that profile definitions are updated
David Holmes
david.holmes at oracle.com
Wed Jan 30 05:04:50 PST 2013
Hi Alan,
This all looks good. My only comments are in Images.gmk. This seems a
rather awkward way of making sure that the check happens after the jars
exist:
+ PROFILE_JARS := $(filter %.jar, $(JRE_LIB_TARGETS))
+
+ PROFILE_JARS_CHECKED := $(IMAGES_OUTPUTDIR)/lib$(PROFILE)/_jars_checked
+
+ $(PROFILE_JARS_CHECKED) : $(PROFILE_JARS)
You could just add the toolcheck as the recipe for the presently-empty
profiles-image target?
Also note that PROFILE_JARS is already a variable in Profiles.gmk which
is included by Images.gmk. I don't think the two uses will conflict but
it would be confusing to have them both use the same variable.
Cheers,
David
On 30/01/2013 4:39 AM, Alan Bateman wrote:
>
> One issue with the profiles build is that it's very fragile, in
> particular it's very easy for the definitions in
> profile-rtjar-include.txt to get out of sync with the code (especially
> as new features are coming new and things are moving around).
>
> To help this, I'd like to run a simple tool in the profiles build that
> checks the dependencies to ensure that there aren't references to types
> that do not exist. This will ensure that the profiles build fails for a
> significant number of scenarios where updates to the profiles
> definitions will be needed.
>
> The proposed changes are here:
>
> http://cr.openjdk.java.net/~alanb/8007097/webrev/
>
> A couple of things to note about the changes are:
>
> 1. To date we've been pushing the profiles work to jdk8/profile without
> formal review. That forest is mostly frozen now as David Holmes has
> gathered the changes into a staging forest with a view to pushing them
> to jdk8/build after they have been tested. This means these proposed
> changes might have to wait a bit until there is somewhere to push the
> changes.
>
> 2. There are a small number of references to types that do not exist,
> particularly in compact1 and compact2 because of references to Kerberos
> types in jsse.jar. The profiles build doesn't currently filter out
> classes from jsse.jar and there are implementation (not API) classes in
> jsse.jar that shouldn't really be present in compact1 and compact2.
> There are also a couple of other residual issues that will resolve
> themselves in time. To allow for these issues the tool has a
> refs.allowed file with the exceptions and the tool won't fail because of
> references that are in this file.
>
> 3. It's important that running this tool doesn't impact the build
> performance. In my local environment then it adds 4-5 seconds to the
> "profiles" build, no impact to images of course.
>
> 4. The updates to profile-rtjar-includes.txt can be ignored, they will
> need to go via a different bug ID.
>
> 5. RemoveMethods is moved in the webrev, it somehow ended up in the
> wrong directory (which is harmless as it compiled into the right
> location during the build).
>
> That's mostly it, the main thing I need feedback on is the updates
> jdk/makefiles/*. I believe they are okay and have no impact whatsoever
> on non-profile builds.
>
> -Alan.
>
>
>
More information about the build-infra-dev
mailing list