From harmony-dev-return-17655-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Tue Oct 31 10:46:26 2006 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 41958 invoked from network); 31 Oct 2006 10:46:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 31 Oct 2006 10:46:25 -0000 Received: (qmail 3462 invoked by uid 500); 31 Oct 2006 10:46:35 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 2944 invoked by uid 500); 31 Oct 2006 10:46:34 -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 2935 invoked by uid 99); 31 Oct 2006 10:46:34 -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 02:46:34 -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: error (herse.apache.org: local policy) 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 02:46:21 -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 885A051977 for ; Tue, 31 Oct 2006 05:45:38 -0500 (EST) Message-ID: <4547295A.4030803@pobox.com> Date: Tue, 31 Oct 2006 05:45:46 -0500 From: "Geir Magnusson Jr." 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> <452174E1.8040907@pobox.com> <4522B3C0.7070109@gmail.com> <4522BE88.4070307@pobox.com> <4ed33be10610191051x5afe1324x3ba0af79f7fc2c73@mail.gmail.com> <4ed33be10610300955o2a5f52a3x8b2a53c1bbe8eca8@mail.gmail.com> <45468D12.5080004@pobox.com> <200610310951.k9V9par1031532@d06av02.portsmouth.uk.ibm.com> In-Reply-To: <200610310951.k9V9par1031532@d06av02.portsmouth.uk.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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'? Yes please! > > I'm not actually sure calling it build is a good idea because a number > of common projects use build to contain built artifacts. And many use "target". > What is your > objection to 'make'? Why not "ant"? (joking) Because 'make' just appears really unconventional to me. > >>> 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. it works with your idea from your other post of just pulling out as-is now. > >>> 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? >>>>>>>> >>>>>>>> geir >>>>>>>> >>>>> --------------------------------------------------------------------- >>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html >>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org >>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org >>>>> >>>>> >>>> -- >>>> Thank you. >>>> Ilya Neverov, >>>> Intel Middleware Products Division >>>> > > >