Mark Hindess wrote:
On 30 October 2006 at 18:38, "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
Ilya Neverov 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.
Cool
I think the following structure will be appropriate for future
evolution of the jdktools:
jdktools/trunk/
build.xml
make/
Can we stop persisting this mistake? Please call it "build" :)
And call 'build' something else like 'target'?
Yes please!
I'm not actually sure calling it build is a good idea because a number
of common projects use build to contain built artifacts.
And many use "target".
What is your
objection to 'make'?
Why not "ant"? (joking)
Because 'make' just appears really unconventional to me.
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/
Only comment is that we might want to pull the launcher out to be a
peer. Otherwise, I like it.
I'd be a little tempted by that idea too.
it works with your idea from your other post of just pulling out as-is now.
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);
yes - think of the same trick we do w/ DRLVM to "reach over" to find it.
I'd imagine the federated build to then have :
trunk/
working_classlib/
working_vm/
working_jdktools/
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.
That's one reason why I'd pull the launcher out to it's own module
I'm rather newbie in the Harmony build system so your thoughts will be
very helpful.
Ant and make will be your friends here :) Note that you will have
native issues (because of the launcher), so please track the way that
classlib does this wrt platforms to start, and if you find things that
work better, suggest it. Mark and Ollie are wizards here.
I'd suggest starting out to accommodate (windows,linux) X (x86, x86_64)
if you grok what I mean, and do it in a way that it will be trivial to
add other OSs or processor architectures (IPF, for example).
This might be a good place to figure out how this should work going
forward for harmony, rather than experimenting in classlib.
+1
Thank you
No, thank you :)
+1
Regards,
Mark.
geir
-Ilya
On 10/19/06, Ilya Neverov <[EMAIL PROTECTED]> wrote:
Hi Geir,
Looks like that creating the "jdktools" source tree and build was
shaded by other tasks. I can help with preparing and checking updates
in the build system. Please let me know what needs to do in this area
(besides svn commits) to complete the task.
I'm especially interested in completing the move to "jdktools"
structure since there will be a home for the JDWP code, which has beed
voted but still resides in JIRA. Working with SVN will be easier.
Thanks.
-Ilya
On 10/4/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
yep, that's the plan. And once we have that, we can simplify the
launcher as well...
Tim Ellison wrote:
+1 for creating a jdktools directory. The dependency on the classlib
launcher should be relatively light if we go with a simple tools
launcher that rewrites the tool invocation into a generic launcher
invocation. You may recall the idea was discussed a while ago.
So, for example,
jdk/bin/javac -source 1.5 -J-Xmx200M FooBar
is rewritten to
jdk/jre/bin/java -cp jdk/lib/tools.jar;jdk/lib/ecj.jar -Xmx200M
org.apache.harmony.tools.javac.Main -source 1.5 FooBar
and so on.
Regards,
Tim
Geir Magnusson Jr. wrote:
Geir Magnusson Jr. wrote:
Now that we have javac, javah, javap (if Tim votes ;) and
keytool, I'd
like to organize these and add them to the next snapshot.
My bad - the javap isn't being voted on yet. I was thinking of
the jdwp
vote... sorry
So I propose adding a new top-level directory called "jdktools"
(and
rename "tools" to "project_tools") and create a build target that -
with a dependency on classlib for the launcher - creates the
'stuff'
needed to fill into the JDK.
Any comments?
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Thank you.
Ilya Neverov,
Intel Middleware Products Division
