harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Chernyshev" <a.y.chernys...@gmail.com>
Subject Re: Supporting working on a single module?
Date Mon, 15 May 2006 12:14:53 GMT
Hi Oliver,

> 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

The current layout is just fine with me as well, in general. I just
thought that, once a big movement over a filesystem starts, it could
be a good chance to remove a few extra levels, in case we find them
redundant. If we don't think they are redundant, then let them leave
as they are.

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

Actually I thought of having the BidiWrapper.c, for example, directly
under the modules/text/src/main/native dir (if  not considering
various OSes and platforms at this time:)). Since we already have a
'text' directory once in the beginning of the path, it may probably
look a bit excessive to repeat it once again at the end.

Thanks,
Andrey.


On 5/15/06, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> 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
>
>

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