> >
> > With best regards,
> >
> > 2006/10/31, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
> >> 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 <[EMAIL PROTECTED]> 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'?
> >> >>
> >> >> 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 <[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?
> >
> >
>
