Preliminary request for review: 7025066 Build system changes to support SE Embedded integration
David.Holmes at oracle.com
Thu Mar 10 22:49:35 PST 2011
FYI I accidentally nuked all my webrevs on cr.openjdk.jav.net.
I'll send out new review requests and webrevs next week.
David Holmes said the following on 03/11/11 11:50:
> Dr Andrew John Hughes said the following on 03/11/11 11:02:
>> On 17:35 Thu 10 Mar , David Holmes wrote:
>>> Sorry, this was just a preliminary RFR so I didn't set up the webrev
>> My issue was more a personal distaste for webrevs than anything you did
>> wrong. I just find it much easier if everything is in the e-mail and
>> can be commented on inline rather than on some website that has to be
>> loaded up in a separate window and can change or even disappear. It's
>> especially true for big patches like this, where you really need to
>> break the patch down in the mail.
> We'll have to agree to disagree there. The webrev should be un-changing
> - that was my fault. webrev is far superior to patches in emails.
> Patches in emails only work when they are very small and you don't have
> to be able to determine the context of the patch to understand it.
>>> I'm looking into a new structure where the JAVASE_EMBEDDED stuff is
>>> factored out into Defs-embedded.gmk and Release-embedded.gmk. This
>>> will relegate the reduced-jre targets to being relevant to embedded
>>> only and anyone not interested just doesn't look in those files.
>> My fear is not so much Makefile clutter as that untested options can
>> bit rot.
>> People make modifications in one area and these unused options are
>> That's actually more likely if you squirrel it away in a separate file.
> Well the separate file is our concern as we will be using it - no bit
> rot there. The concern we have (Embedded group) when we have these
> additions to add cross-compilation etc is that the other teams are not
> aware of them and so, for example, they may add a new build tool that
> has to be compiled at build time and they use $(CC) not realizing they
> should use $(HOST_CC). But again we will hit that pretty quickly and can
> then make a correction. And hopefully, over time as people are more
> aware of cross-compilation, for example, they will know these things to
> watch out for.
> By "hiding" things like the reduced-jre targets in the
> Release-embedded.gmk we avoid people trying to use them out of context.
> I'd like to do the same with BUILD_CLIENT_ONLY but it's somewhat more
> intrusive, without making a lot of changes to do existence tests prior
> to copying etc.
More information about the build-dev