Improving the management and accessibility of the handling of JDK variants

[David Holmes]

On 19/11/2013 3:25 AM, Volker Simonis wrote:
> Hi Dave,
>
> what you are trying to achieve sounds a little bit like Oracles
> "closed" build. As far as I know, they allow for extra directories
> (which are realized as Mercurial forests on their own) which can be
> linked into the open sources at special "mount points". Just grep for
> CLOSED_SOURCE_PRESENT in the top level repository or do a "grep -ri
> closed" in the jdk/makefiles directory. This will give you the basic
> idea.

Yes - though the name of the "closed" thing varies depending on what it is:

- configure:  CUSTOM_CONFIG_DIR
- jdk build: CUSTOM_MAKE_DIR
- hotspot build: HS_ALT_MAKE
- hotspot sources: HS_ALT_SRC
- jdk source: *CLOSED_SRC_DIRS

the open/closed splits happened to different pieces at different times 
by different people. We tried tried to abstract away the "closed" part 
with ALT or CUSTOM in more recent times.

Of course these configuration points have been defined based on our 
needs for the Oracle JDK versus OpenJDK, so there is no claim of general 
applicability or suitability for all potential users who want to 
customize the build and/or sources. Happy to adapt in reasonable ways of 
course.

Cheers,
David Holmes


> Regards,
> Volker
>
>
> On Mon, Nov 18, 2013 at 4:40 PM, Dave Pointon
> <dpointo8 at linux.vnet.ibm.com> wrote:
>> Hi all ,
>>
>> Whilst investigating the building of the IBM variant of the JDK, I very
>> quickly realized that not all build variant build configurations will be
>> identical e.g. the IBM variant requires such things as the
>> removal/addition of files from/to the local repo, variant specific
>> compiler &/or linker flags etc.
>>
>> On further reflection, I became convinced that the  handling of any such
>> build variants should be as flexible/scalable (and thus useful :-) as
>> possible. Ergo, any implementation should provide significant benefits
>> by way of a reduction in effort required in order to support further
>> variants.
>>
>> Initial code inspections and experiments suggest that the most scalable
>> means of introducing the ability to build the IBM variant of the JDK,
>> might be achieved thro' the use of the --with-jdk-variant configure
>> option, or an extension of it. Moreover, the implementation should take
>> the form of being able to cater for local draft &/or branch specific,
>> variants whilst, at the same time, minimising any interference with the
>> day-to-day pull's and pushes from the parent repo.
>>
>> At the highest level, my thoughts and indeed experiments, were/are along
>> the lines of ...
>> . Adding a configure option, -with-jdk-variant-base-dir, that specifies
>> a base directory (default - <repo-root>/common/autoconf/jdk-variants) in
>> which would be located a sub-directory for each variant.
>> . Adding jdk-variants.m4 to contain variant validation and processing
>> macros
>> . Updating jdk-options.m4 to utilise the new option validation macro
>>
>>
>> That's about as far as I've got ... as yet, so any & all thoughts WRT
>> this toe-in-the-water, slightly more convoluted, exercise are most
>> welcome ...
>>
>> TIA & rgds ,
>>
>> --
>> Dave Pointon FIAP MBCS
>>
>> Now I saw, tho' too late, the folly of beginning a work
>> before we count the cost and before we we judge rightly
>> of our strength to go thro' with it - Robinson Crusoe
>>