Return-Path: 
 <harmony-dev-return-17686-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org
Received: (qmail 88212 invoked from network); 31 Oct 2006 13:22:10 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 31 Oct 2006 13:22:10 -0000
Received: (qmail 95099 invoked by uid 500); 31 Oct 2006 13:22:18 -0000
Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org
Received: (qmail 94831 invoked by uid 500); 31 Oct 2006 13:22:17 -0000
Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:harmony-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:harmony-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:harmony-dev@incubator.apache.org>
List-Id: <harmony-dev.incubator.apache.org>
Reply-To: harmony-dev@incubator.apache.org
Delivered-To: mailing list harmony-dev@incubator.apache.org
Received: (qmail 94822 invoked by uid 99); 31 Oct 2006 13:22:17 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 31 Oct 2006 05:22:17 -0800
X-ASF-Spam-Status: No, hits=1.4 required=10.0
	tests=SPF_HELO_PASS,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (herse.apache.org: 216.86.168.178 is neither permitted
 nor denied by domain of geir@pobox.com)
Received: from [216.86.168.178] (HELO mxout-03.mxes.net) (216.86.168.178)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 31 Oct 2006 05:22:01 -0800
Received: from [192.168.1.104] (unknown [67.86.14.213])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id CC8855194C
	for <harmony-dev@incubator.apache.org>; Tue, 31 Oct 2006 08:21:37 -0500 (EST)
Message-ID: <45474DEA.4060104@pobox.com>
Date: Tue, 31 Oct 2006 08:21:46 -0500
From: "Geir Magnusson Jr." <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [general] creation of "jdktools"
References: <452129AB.6040407@pobox.com>
 <4522BE88.4070307@pobox.com>	 <4ed33be10610191051x5afe1324x3ba0af79f7fc2c73@mail.gmail.com>
	 <4ed33be10610300955o2a5f52a3x8b2a53c1bbe8eca8@mail.gmail.com>
	 <45468D12.5080004@pobox.com>
	 <200610310951.k9V9par1031532@d06av02.portsmouth.uk.ibm.com>
	 <4ed33be10610310202l6d7a62aex4c8f839ee835cc37@mail.gmail.com>
	 <45472A32.8010903@pobox.com>
	 <2c9597b90610310349l5f7cce6fh7d0dbd9d2a3da233@mail.gmail.com>
	 <4547409A.7000902@pobox.com>
 <2c9597b90610310511y1e3a08fdi77a1cbef9aa7bed6@mail.gmail.com>
In-Reply-To: <2c9597b90610310511y1e3a08fdi77a1cbef9aa7bed6@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

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?
>> >
>> >
>>
> 
>