From harmony-dev-return-17690-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Tue Oct 31 13:51:02 2006 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 94870 invoked from network); 31 Oct 2006 13:50:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 31 Oct 2006 13:50:56 -0000 Received: (qmail 72520 invoked by uid 500); 31 Oct 2006 13:50:59 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 72482 invoked by uid 500); 31 Oct 2006 13:50:59 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 72467 invoked by uid 99); 31 Oct 2006 13:50:59 -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:50:59 -0800 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of ilya.neverov@gmail.com designates 64.233.182.186 as permitted sender) Received: from [64.233.182.186] (HELO nf-out-0910.google.com) (64.233.182.186) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 31 Oct 2006 05:50:43 -0800 Received: by nf-out-0910.google.com with SMTP id m18so293734nfc for ; Tue, 31 Oct 2006 05:50:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=U8NNT9wPgG7MHhdQGAG+1EWvpvMX36bT/VFRtqYet7O+WFlfOutHYsgylMIFzQ6hTcQv75hckJlE3nGkyqcqxt0BwH6kfsPliXPDXRmBv3N5FziXo/HNPUTzAsx+nUmStLdedYQWXiQfSYRsegQIPl/mtt9qBxlZVjMctiqVS1g= Received: by 10.82.126.19 with SMTP id y19mr1059888buc; Tue, 31 Oct 2006 05:50:21 -0800 (PST) Received: by 10.82.130.14 with HTTP; Tue, 31 Oct 2006 05:50:21 -0800 (PST) Message-ID: <4ed33be10610310550i5d432b7ep44e1d1e59bee87de@mail.gmail.com> Date: Tue, 31 Oct 2006 19:50:21 +0600 From: "Ilya Neverov" To: harmony-dev@incubator.apache.org Subject: Re: [general] creation of "jdktools" In-Reply-To: <45474DEA.4060104@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <452129AB.6040407@pobox.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> <45474DEA.4060104@pobox.com> X-Virus-Checked: Checked by ClamAV on apache.org 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. 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[.]" as a > > place for storing generated stuff like .class and .jar files, > > generated docs and etc. > > > > Regards, > > > > 2006/10/31, Geir Magnusson Jr. : > >> > >> > >> 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." 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.") > >> > >> What projects? Java projects? > >> > >> > > >> > With best regards, > >> > > >> > 2006/10/31, Geir Magnusson Jr. : > >> >> 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 wrote: > >> >> >> > >> >> >> On 30 October 2006 at 18:38, "Geir Magnusson Jr." > >> >> 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 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. 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? > >> > > >> > > >> > > > > >