Implicit assumptions in Images.gmk: find errors

[Kelly O'Hair]

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