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:33:23 GMT
> 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.

Yes, I was thinking about that too, but didn't mention :).
I remember there was a discussion about this sometime in the past [1],
it looked like most people agreed at that time that keeping OSes &
platforms as the directory names is the preferred choice.

Thanks,
Andrey.

[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200603.mbox/%3c4410328E.4070904@googlemail.com%3e


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

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