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
<dpoin...@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
