harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: Supporting working on a single module?
Date Mon, 15 May 2006 12:30:35 GMT

On 15 May 2006 at 16:14, "Andrey Chernyshev" <a.y.chernyshev@gmail.com> wrote:
> 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.

>From the perspective of that single file/module, then what you say might
be reasonable.  But I think it would be nice to have consistency between
modules so that we can share common functionality between build files.

Regards,
 Mark.

> 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 t=
> he
> > >> foundation and "easy" parts done first, and raising a JIRA for each st=
> ep
> > >> 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 ea=
> sy
> > 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 com=
> e
> > across as intended, so to clarify the resulting native directories will b=
> e:
> >
> >  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 wel=
> l:
> > > 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



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