[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-build-infra-dev
Subject:    Implicit assumptions in Images.gmk: find errors
From:       kelly.ohair () oracle ! com (Kelly O'Hair)
Date:       2012-11-26 16:22:23
Message-ID: E10F62C4-E1BC-43AE-9756-CAA07EB634F8 () oracle ! com
[Download RAW message or body]

The issue I have with the demos, and samples too, is that they should be something a \
customer could use with the delivered jdk image, so building it from a jdk image \
matches what a customer might see. In addition, the demos and samples are being \
pulled out of the default jdk image and being delivered in separate bundles, \
distancing them from the jdk image creation even more.

So I'm fine with the way it is now, but keep in mind that the demos are being more \
and more isolated as we move forward. My tendency is to try and keep them separate, \
more like a required test case for the builds, and a separate deliverable. But for \
now, we can stick with the status quo.

I've done quite a bit of work on the demos in the past, and they are, quite frankly, \
a huge pain in regards to being inconsistent and varied in build procedures. The \
native code ones are particularly difficult, and I wrote many of them. :^( They can \
become a huge time sink. :^(  But their value cannot be denied.

-kto

On Nov 26, 2012, at 12:25 AM, Erik Joelsson wrote:

> The demos are built using the bootstrap javac, running on the boot jdk and linked \
> against the newly built classes. The next step would be executing on the newly \
> built jdk, but I don't think we need to go that far. The end result is logically \
> the same (as in the same compiler is used and the same classes are linked against) \
> and I would rather avoid the complications for cross compilation. 
> /Erik
> 
> On 2012-11-25 19:05, Kelly O'Hair wrote:
> > That sounds right.
> > 
> > The demos really need to be built from the built jdk image.
> > So in my opinion, the demos should follow the jdk image creation.
> > 
> > I think in the old build it was a bit mixed up as to when the demos were built.
> > 
> > -kto
> > 
> > On Nov 23, 2012, at 12:20 AM, Erik Joelsson wrote:
> > 
> > > We could condition these finds on the existence of these directories. I think \
> > > that would be the cleanest implementation as it would logically act the same as \
> > > now, just with less noise and execs. 
> > > /Erik
> > > 
> > > On 2012-11-23 01:19, David Holmes wrote:
> > > > Some of the constructs in Images.gmk implicitly assume that you are always \
> > > > building a JDK image and a JRE image. Ie.: 
> > > > JDK_DEMO_TARGETS := $(patsubst \
> > > > $(JDK_OUTPUTDIR)/demo/%,$(JDK_IMAGE_DIR)/demo/%,\ $(shell $(FIND) \
> > > > $(JDK_OUTPUTDIR)/demo ! \( -name "_the*" -o -name "javac_state" \) )) 
> > > > and:
> > > > 
> > > > # /sample dir
> > > > $(foreach f,$(shell $(FIND) $(JDK_OUTPUTDIR)/sample -type f),\
> > > > $(eval $(call \
> > > > AddFileToCopy,$(JDK_OUTPUTDIR),$(JDK_IMAGE_DIR),$f,JDK_SAMPLE_TARGETS))) 
> > > > 
> > > > will both attempt to issue "find" in a directory that may not exist (jdk/demo \
> > > > and jdk/sample respectively) if you are not building a jdk image. 
> > > > Fortunately (or perhaps erroneously?) these find failures do not cause make \
> > > > to fail, they just generate noisy output (which of course is how I noticed \
> > > > it). 
> > > > Not sure what the solution is or if it is just something we have to live \
> > > > with. There is an awful lot of setup needed to build images, but some of it \
> > > > is dependent on what image has been requested. 
> > > > Cheers,
> > > > David


[prev in list] [next in list] [prev in thread] [next in thread]