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? > 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! Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
