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:32:35 GMT
Hi Andrey,


Andrey Chernyshev wrote:
> On 5/12/06, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
>> Geir Magnusson Jr wrote:
>>
<SNIP>
>>
>> >>
>> >> To do this there are at least three steps needed, as far as I can 
>> see:
>> >>
>> >> 1) Refactor the native code into the modular structure we currently
>> >> have for Java code and tests. This has been spoken about before at
>> >> [1]. The native code would be located within each module at
>> >> modules/<module name>/src/main/native. As a starting point, can I
>> >> propose that the natives be broken down in the following way:
>> >>
>> >> modules/archive/src/main/native/
>> >>                                        |-------archive/
>> >>                                        |-------zip/
>> >>
>> >> +------zlib/                          modules/auth/src/main/native/
>> >>                                        +-------auth/
>> >>
>> >> modules/luni/src/main/native/
>> >>                                        |--------common/
>> >>                                        |--------fdlibm/
>> >>                                        |--------launcher/
>> >>                                        |--------luni/
>> >>                                        |--------pool/
>> >>                                        |--------port/
>> >>                                        |--------sig/
>> >>                                        |--------thread/
>> >>                                        |--------vmi/
>> >>                                        +-------vmls/
>> >>
>> >> modules/prefs/src/main/native/
>> >>                                       +-------prefs/
>> >>
>> >> modules/text/src/main/native/
>> >>                                        |-------text/
>> >>                                        +------unicode/ (comes from
>> >> the icu4c zips stored currently in depends)
>> >
>> > W/o thinking too hard about it, this works for me just fine.
>>
>> Great - I am starting to look at how shared includes can be handled
>> across modules (as Mark alluded to in his earlier post in this thread
>> [1]), and at what changes will be required to split the natives into
>> these locations. I will be taking this in small steps, trying to get the
>> foundation and "easy" parts done first, and raising a JIRA for each step
>> rather than in one monolithic change.
>
> Great!  I think splitting the sources by modules at the top level
> directory is a good idea.
> A few questions before the big source tree reorganization starts:
>
>> >> modules/archive/src/main/native/
>> >>                                        |-------archive/
>> >>                                        |-------zip/
>
> (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 :))

I think using "src/main" and "src/test" to group our implementation
and test code was a convention we agreed on a while back. Personally
I dont have any problem with it, but it's something we can look at again
if people don't like it. I think that's something that would be fairly easy
to alter once the natives are modularised, should we wish to do so.


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

Maybe I am missing something, but I think what you're suggesting (putting
port etc. directly under the native directory) is the same as I laid out 
above -
it's quite likely that my ascii diagram of the directory layout hasnt come
across as intended, so to clarify the resulting native directories will be:

 modules/archive/src/main/native/archive/
 modules/archive/src/main/native/zip/
 modules/archive/src/main/native/zlib/

 modules/luni/src/main/native/common/
 modules/luni/src/main/native/fdlibm/
 modules/luni/src/main/native/launcher/
 modules/luni/src/main/native/luni/
 modules/luni/src/main/native/pool/
 modules/luni/src/main/native/port/
 modules/luni/src/main/native/sig/
 modules/luni/src/main/native/thread/
 modules/luni/src/main/native/vmi/
 modules/luni/src/main/native/vmls/

 modules/prefs/src/main/native/prefs/

 modules/text/src/main/native/text/
 modules/text/src/main/native/unicode/

I think this agrees with what you were saying - please let me know if 
I've misunderstood!

>
>
> BTW, I've noticed that this proposal is very similar to the DRLVM
> source tree organization, which is like:
> - 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.
>

Once the initial move of native code into the modules is completed,
any way to enhance and better modularise the build system would be
welcome! I will take a look at the DRLVM build system to see how
the independent modules are handled there.

Regards,
Oliver

>
> Thank you,
> Andrey Chernyshev
> Intel Middleware Products Division
>
>

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