RFR: JDK-8071767 Improve names and dependencies for image targets

[Erik Joelsson]

OK from me.

/Erik

On 2015-02-06 12:29, Magnus Ihse Bursie wrote:
> On 2015-02-06 12:16, Magnus Ihse Bursie wrote:
>> On 2015-02-05 08:12, David Holmes wrote:
>>> Hi Magnus,
>>>
>>> Thanks for the detailed background - makes things a lot clearer! It 
>>> would be useful for a synopsis to be included in the makefile along 
>>> with the functional changes.
>>
>> So I joined forces with Ingemar and extended his patch with some 
>> comments derived from my mail.
>>
>> New webrev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8071767-improved-global-make-targets/webrev.02
>
> There was some language misses in that webrev. I have replaced
> "These can now be considered alias for the targets now named by a more 
> ..."
> with
> "These can be considered aliases for the targets now named by a more..."
> but I'm not sending  out a new webrev for that.
>
> /Magnus
>
>
>>
>> /Magnus
>>
>>>
>>> David
>>>
>>> On 4/02/2015 10:20 PM, Magnus Ihse Bursie wrote:
>>>> On 2015-02-04 09:33, David Holmes wrote:
>>>>> On 3/02/2015 11:17 PM, Ingemar Aberg wrote:
>>>>>> Some of the target names in the makefiles are inconsistent and 
>>>>>> does not
>>>>>> clearly reflect what they do. They should be improved but the old 
>>>>>> names
>>>>>> should be kept as aliases for people who are used to them.
>>>>>>
>>>>>> Examples:
>>>>>>
>>>>>> images -> product-images
>>>>>> docs -> docs-image
>>>>>
>>>>> I find "images" and "docs" quite clear as-is. I don't understand what
>>>>> a "docs-image" might be. And "product" is totally subjective and
>>>>> easily confused with a "release" build versus fastdebug etc.
>>>>>
>>>>> Maybe because of things like "exploded-image" (which is what? what is
>>>>> the unexploded image?) the use of "image" alone is less clear, but
>>>>> still "product-image" doesn't seem right.
>>>>
>>>> Since I was the one suggesting these names, let me elaborate a bit.
>>>>
>>>> The driving force behind these name changes is the ongoing effort of
>>>> test co-location, that is integrating test source code more closely 
>>>> with
>>>> the product code, and integrating the build of said tests with the
>>>> existing build framework.
>>>>
>>>> So when historically the build system has, more or less (this is an
>>>> oversimplification but it's enough for this discussion), only built 
>>>> the
>>>> actual bits to be shipped to the customer (the "product"), this 
>>>> will no
>>>> longer be the case. So we need to have target names that clearly
>>>> separates wether we build the "product" (that is, the things we build
>>>> from the various "src" directories in the repos), from tests, and 
>>>> other
>>>> things we deliver (like documentation).
>>>>
>>>> If you have a better suggestion than "product", please let me hear! 
>>>> Just
>>>> not "jdk", it's overloaded in meanings as it is.
>>>>
>>>> As part of the Jigsaw M2 effort, we spent quite some time getting a 
>>>> more
>>>> consistent and predictable structure of the build output directory.
>>>> Unfortunately, we might not have communicated this effort clearly
>>>> outwords. :-( What we have, in the post-M2 world, is the following 
>>>> build
>>>> output structure:
>>>> $BUILD/
>>>>    support/ <-- here we put build-internal and intermediate files, 
>>>> such
>>>> as generated source or .o files
>>>>    jdk/ <-- here we put, like before, a "runnable"/"exploded" jdk.
>>>>    images/ <-- here we put the "deliverables" that is the final result
>>>> of the build
>>>>
>>>> I personally would have chosen a different name for the deliverables
>>>> than "images", but it was decided to keep this legacy name for 
>>>> practical
>>>> reasons. So, with this terminology, "images" means "the end result, 
>>>> our
>>>> deliverables".
>>>>
>>>> The images directory contains a number of, eh, images, like "jre" or
>>>> "jdk", or some other Oracle internal ones, or special Mac OSX bundles,
>>>> etc. Or the docs image.
>>>>
>>>> And now we are adding "images/test", that is, the test image.
>>>>
>>>> So, then, what would you expect to build when building "images"? Or 
>>>> when
>>>> building "all"?
>>>>
>>>> I argued that "all" should build all our images (that is, it's an 
>>>> alias
>>>> for "all-images"). And that "all" our images consisted of three types:
>>>> * the test image [test-image]
>>>> * the docs image [docs-image]
>>>> * the product images [product-images]
>>>>
>>>> I also argued that "images" has traditionally meant just the
>>>> product-images (and not docs), and thus should not include test-images
>>>> now either (in contrast to "all"). (This was by no means the way 
>>>> other,
>>>> more test-oriented people originally interpreted the target name.)
>>>>
>>>> So this change clarifies that
>>>>
>>>> all-images: product-images test-image docs-image
>>>>
>>>> and that we have a set of "traditional" targets which are now 
>>>> rather to
>>>> be considered aliases to targets with more standardized names, 
>>>> which has
>>>> developed as the build system has grown:
>>>>
>>>> default: exploded-image
>>>> jdk: exploded-image
>>>> images: product-images
>>>> docs: docs-image
>>>> all: all-images
>>>>
>>>> As for the name "exploded image", I think it's a good candidate for
>>>> Worst Name Ever. :-( I'd replace it in a second if I could come up 
>>>> with
>>>> a better name. Suggestions are welcome!
>>>>
>>>> So, I believe this is a good change that lays the foundation for a 
>>>> more
>>>> clear set of targets when we move forward with the test co-location.
>>>>
>>>> /Magnus
>>
>