Hi Andrey,
Andrey Chernyshev wrote:
On 5/12/06, Oliver Deakin <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
