Preliminary request for review: 7025066 Build system changes to support SE Embedded integration

David Holmes David.Holmes at oracle.com
Fri Mar 11 06:49:35 UTC 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

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 
>>> versioning.
>>>
>>
>> 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 
>> missed.
>> 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.
> 
> Cheers,
> David



More information about the build-dev mailing list