harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [general] creation of "jdktools"
Date Wed, 01 Nov 2006 01:32:19 GMT


Nathan Beyer wrote:
> On 10/31/06, Mark Hindess <mark.hindess@googlemail.com> wrote:
>>
>> On 31 October 2006 at 7:24, "Geir Magnusson Jr." <geir@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. <geir@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.hindess@googlemail.com>
wrote:
>> > >> >>
>> > >> >> On 30 October 2006 at 18:38, "Geir Magnusson Jr." 
>> <geir@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.neverov@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. <geir@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?
>> > >
>> > >
>> >
>>
>>
>>
> 

Mime
View raw message