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 Tue, 31 Oct 2006 14:01:58 GMT
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. <geir@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. <geir@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. <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