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 
modules/luni/src/main/native/port
directory there would be the following structure (avoiding ascii tree 
diagrams):

 modules/luni/src/main/native/port/shared
 modules/luni/src/main/native/port/linux
 modules/luni/src/main/native/port/windows

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

Agreed!

> 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


Mime
View raw message