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 10:45:46 GMT


Mark Hindess 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'?

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

Mime
View raw message