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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
