You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Nathan Beyer <nb...@gmail.com> on 2006/11/01 01:44:23 UTC
Re: [general] creation of "jdktools"
On 10/31/06, Mark Hindess <ma...@googlemail.com> wrote:
>
> On 31 October 2006 at 7:24, "Geir Magnusson Jr." <ge...@pobox.com> wrote:
> >
> >
> > 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?
>
> ?
>
> Apache Jakarta Commons Collections uses build/classes and build/tests
> for artifacts... just like classlib does.
>
> -Mark.
Every project that uses Maven 2 (including the Maven projects
themselves) use "target" as the general output directory,
"target/classes" as the compiled output (class files and resources)
and "target/test-classes" as the compiled test output (class files and
resources). The build instructions (script) is just placed in the root
of the project.
This is the default behavior of an minimally configured Maven 2
project, which is supposedly based on the ASF best practices. If we're
trying to converge on a common structure, I'd suggest following the
conventions of the Maven 2 system.
-Nathan
>
> > >
> > > 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 <ma...@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 <il...@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?
> > >
> > >
> >
>
>
>
Re: [general] creation of "jdktools"
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Nathan Beyer wrote:
> On 10/31/06, Mark Hindess <ma...@googlemail.com> wrote:
>>
>> On 31 October 2006 at 7:24, "Geir Magnusson Jr." <ge...@pobox.com> wrote:
>> >
>> >
>> > 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?
>>
>> ?
>>
>> Apache Jakarta Commons Collections uses build/classes and build/tests
>> for artifacts... just like classlib does.
>>
>> -Mark.
>
> Every project that uses Maven 2 (including the Maven projects
> themselves) use "target" as the general output directory,
> "target/classes" as the compiled output (class files and resources)
> and "target/test-classes" as the compiled test output (class files and
> resources). The build instructions (script) is just placed in the root
> of the project.
>
> This is the default behavior of an minimally configured Maven 2
> project, which is supposedly based on the ASF best practices. If we're
> trying to converge on a common structure, I'd suggest following the
> conventions of the Maven 2 system.
As you noted, the maven 2 approach came from best practices, not the
other way around.
I felt that needed to be restated ;)
geir
>
> -Nathan
>
>
>>
>> > >
>> > > 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 <ma...@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 <il...@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?
>> > >
>> > >
>> >
>>
>>
>>
>