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. Thanks, Andrey. On 5/15/06, Oliver Deakin <[EMAIL PROTECTED]> wrote:
Hi Andrey, Andrey Chernyshev wrote: > On 5/12/06, Oliver Deakin <[EMAIL PROTECTED]> 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 the >> foundation and "easy" parts done first, and raising a JIRA for each step >> 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 easy 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 come across as intended, so to clarify the resulting native directories will be: 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 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. > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
