On 30 October 2006 at 23:55, "Ilya Neverov" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I want to gather opinions about structure of the "jdktools" component.
>
> I'm going to create scripts for moving tools' sources from classlib/
> to top-level directory jdktools/ and to prepare patches for build
> system for building tools from new place.
Excellent!
Some general comments (that others might disagree with?):
1) Don't copy the classlib build practice of using separate build.xml
files from java, natives and documentation. Or at least, if you do use
import rather than antcall. Why? Well, besides being more efficient,
importing allows ant dependency resolution to work across all build
files.
2) Consider using subant for the modules, you may need to make it two
stages[0] ... first do modules/jre using a trivial subant task, then a
second subant task to do everything but modules/jre.
3) I recently added the build/ant/properties.xml to the hdk which
contains platform definitions, build/make also contains native code
defines. You should try to use these if possible. (If there are other
things I've missed let me know - this was just the first thing that came
up in my recent abortive attempt to do item 4.)
4) I thought the easiest way to start the tool launcher might be
to just copy (svn copy even) the current launcher. At least we'd
have something that worked. It would then be possible to hack the
java launcher to remove the tools specific code and the tool launcher
could be hacked to remove the vm initialisation code - it should be
replaced with exec("java", ...).
> I think the following structure will be appropriate for future
> evolution of the jdktools:
>
> jdktools/trunk/
> build.xml
> make/
> doc/
> modules/
> jre/ # keytool, tool launcher go here
> build.xml # classes go to jdk/jre/lib/tools.jar
> make/
> src/
> jdk/ # javac, jarsigner go here
> build.xml # classes go to jdk/lib/tools.jar
> make/
> src/
> jdwp/ # separate module for large component
> build.xml
> make/
> src/
Looks reasonable.
> Assumptions which look reasonable for jdktool's build subsystem:
>
> 1) it works in presence of built classlib (as HDK binaries or as a
> result of classlib phase of overall build);
I think it should be an HDK (with hy.hdk defaulting to
"../classlib/deploy" but with a user properties file to override it).
Perhaps something like:
<property file="${user.home}/.harmony-tools.properties" />
<property name="hy.hdk" location="../classlib/deploy" />
> 2) the 'jre' module is always built before building 'jdk' to provide
> generic tool launcher and the jre/lib/tools.jar. Probably it will be
> easy to obtain these items from HDK.
Hmm... Geir was not in favour of updating the hdk directly IIRC?
Perhaps consider a separate deploy tree to begin with.
> I'm rather newbie in the Harmony build system so your thoughts will be
> very helpful.
Fresh eyes are great. It's often useful to have to justify/describe
why/how we are doing things - it makes us think again about our
decisions.
Regards,
Mark.
[0] Statements like this usually trigger Matt Benson to appear on the
list telling me the neat trick for doing this elegantly. ;-)
