harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Supporting working on a single module?
Date Sun, 14 May 2006 04:21:35 GMT
Andrey Chernyshev wrote:

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

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



Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

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

View raw message