39 messages in org.apache.harmony.devRe: [general] creation of "jdktools"| From | Sent On | Attachments |
|---|---|---|
| Geir Magnusson Jr. | Oct 2, 2006 8:00 am | |
| Geir Magnusson Jr. | Oct 2, 2006 1:21 pm | |
| Tim Ellison | Oct 3, 2006 12:02 pm | |
| Ivan Popov | Oct 3, 2006 12:41 pm | |
| Geir Magnusson Jr. | Oct 3, 2006 12:48 pm | |
| Salikh Zakirov | Oct 4, 2006 2:06 am | |
| Alexey Varlamov | Oct 4, 2006 2:23 am | |
| Alexei Zakharov | Oct 5, 2006 2:13 am | |
| Tim Ellison | Oct 5, 2006 2:58 am | |
| Tim Ellison | Oct 5, 2006 3:00 am | |
| Geir Magnusson Jr. | Oct 5, 2006 7:05 am | |
| Ilya Neverov | Oct 19, 2006 10:51 am | |
| Ilya Neverov | Oct 30, 2006 9:54 am | |
| Tim Ellison | Oct 30, 2006 10:17 am | |
| Geir Magnusson Jr. | Oct 30, 2006 3:38 pm | |
| Mark Hindess | Oct 31, 2006 1:43 am | |
| Mark Hindess | Oct 31, 2006 1:51 am | |
| Ilya Neverov | Oct 31, 2006 2:02 am | |
| Alexei Zakharov | Oct 31, 2006 2:30 am | |
| Geir Magnusson Jr. | Oct 31, 2006 2:45 am | |
| Geir Magnusson Jr. | Oct 31, 2006 2:48 am | |
| Alexei Zakharov | Oct 31, 2006 3:48 am | |
| Geir Magnusson Jr. | Oct 31, 2006 4:24 am | |
| Alexei Zakharov | Oct 31, 2006 5:10 am | |
| Geir Magnusson Jr. | Oct 31, 2006 5:21 am | |
| Ilya Neverov | Oct 31, 2006 5:49 am | |
| Geir Magnusson Jr. | Oct 31, 2006 6:01 am | |
| Ivan Popov | Oct 31, 2006 6:43 am | |
| Mark Hindess | Oct 31, 2006 7:22 am | |
| Ilya Neverov | Oct 31, 2006 7:43 am | |
| Alexey Petrenko | Oct 31, 2006 12:35 pm | |
| Nathan Beyer | Oct 31, 2006 4:44 pm | |
| Geir Magnusson Jr. | Oct 31, 2006 5:31 pm | |
| Ilya Neverov | Nov 11, 2006 8:19 am | |
| Nathan Beyer | Nov 11, 2006 11:36 am | |
| Ilya Neverov | Nov 12, 2006 8:51 am | |
| Nathan Beyer | Nov 12, 2006 11:16 am | |
| Geir Magnusson Jr. | Nov 12, 2006 3:43 pm | |
| Ilya Neverov | Nov 13, 2006 1:30 pm |
| Subject: | Re: [general] creation of "jdktools" | |
|---|---|---|
| From: | Geir Magnusson Jr. (ge...@pobox.com) | |
| Date: | Oct 31, 2006 6:01:35 am | |
| List: | org.apache.harmony.dev | |
it's "build" in DRLVM, and "make" (invoked by the build.xml) in classlib.
It wouldn't be inconsistent.
geir
Ilya Neverov wrote:
My perception of 'make' and 'build' names is similar to what Alexei described. I believe that for most people 'make' is a thing related to making/building process while 'build' is more ambiguous.
Currently we have build system with many 'make/' dirs so it probably bettre to postpone the move to new name to some moment of restructuring the whole build system. I think today it's better to keep consistency.
Thanks -Ilya
On 10/31/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
I see. I'm familiar with "target" as the place for stuff that's created...
Alexei Zakharov wrote:
In other words: I just wanted to say that the big number of java projects I've been working with was using "build[.<something>]" as a place for storing generated stuff like .class and .jar files, generated docs and etc.
Regards,
2006/10/31, Geir Magnusson Jr. <ge...@pobox.com>:
Alexei Zakharov wrote:
Take me for example. I will be most likely misleaded with "build" since the majority of projects I've seen in my life were using "build" or "build.<platform>" for storing build artifacts (as Mark said). I agree it is logically to call it "build". But "make" is logical too. "ant" or "ant.scripts" also sound not so bad. Why not to choose the less confusing name?
(I believe you meant "make" or "make.<platform>")
What projects? Java projects?
With best regards,
2006/10/31, Geir Magnusson Jr. <ge...@pobox.com>:
Why? I'm really curious about this. We "build" the project, using the "build.xml" file with Ant.
Ilya Neverov wrote:
I would prefer to keep the current name "make" for directories related to build system. For me it looks natural; at least it looks less misleading than "build" :)
-Ilya
On 10/31/06, Mark Hindess <mark...@googlemail.com> wrote:
On 30 October 2006 at 18:38, "Geir Magnusson Jr."
<ge...@pobox.com>
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'?
I'm not actually sure calling it build is a good idea because a number of common projects use build to contain built artifacts. What is your objection to '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/
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.
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 <ilya...@gmail.com> 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. <ge...@pobox.com> 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?