harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: Supporting working on a single module?
Date Mon, 15 May 2006 09:37:29 GMT

Tim Ellison wrote:
> Andrey Chernyshev wrote:
> <snip>
>> (1) Do we need to keep the 'main' directory in every module? If we
>> need to have a distinction between tests and sources, may be just pull
>> tests one level up and have something like:
>> archive/
>>        src/
>>             native/
>>             java/
>>         tests/
>>             native/
>>             java/
>> I wonder if 'main' is an extra level of the directory tree we can
>> actually avoid of (lazy people don't like typing cd too much :))
> Really lazy people use path completion and don't care ;-)
>> (2) Why do we need to have 'luni' two times in the path, e.g.
>> modules/luni/src/main/native/luni/ ? If we need to put an additional
>> stuff like 'port' to the luni module, perhaps it could be just enough
>> to put it into a subdirectory within native, e.g:
>> modules/luni/src/native/port/ ?
> Is it just the name of that path element that you object to?  Seems a
> bit cleaner to me if there is a bucket to put that source in.
> However, (comment to Oliver as well), I'm left wondering where the
> platform-specific vs. common code distinction is made?

I was thinking that platform specific directories would be laid out 
underneath each native
component directory. So, for example, underneath the 
directory there would be the following structure (avoiding ascii tree 


with further platform specific directories being added as we expand.

>> BTW, I've noticed that this proposal is very similar to the DRLVM
>> source tree organization, which is like:
> Great minds and all that :-)
>> - vm
>>    - include  - top level include which contains h files exported by
>> various VM components;
>>    - interpreter
>>    - jitrino
>>    - vmcore
>>    ...
>>    <other VM components>
>> The module vmcore, for example, contains both native and java code:
>> vmcore/src/kernel_classes
>>       - native
>>       - javasrc
>> The building system for DRLVM has been designed in a modular way as well:
>> There is a "building engine part at the build/make and
>> build/make/targets directory which is shared by all components,
>> Each VM module has a building descriptor which is currently located at
>> build/make/components directory, but can also be easily moved to the
>> component source tree to support the idea of full independent checkout
>> of a specific module.
>> I think the building system provided with DRLVM can easily be used to
>> support the source modularization approach, the proposed 'hdk' in that
>> case would provide the developers, besides the "public includes", with
>> the shared part of the building scripts as well.
> We should continue to collaborate on finding the best solution -- it has
> worked very well so far!


> Regards,
> Tim

Oliver Deakin
IBM United Kingdom Limited

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

View raw message