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
