On 15 May 2006 at 16:14, "Andrey Chernyshev" <[EMAIL PROTECTED]> wrote: > 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.
>From the perspective of that single file/module, then what you say might be reasonable. But I think it would be nice to have consistency between modules so that we can share common functionality between build files. Regards, Mark. > 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 t= > he > > >> foundation and "easy" parts done first, and raising a JIRA for each st= > ep > > >> 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 ea= > sy > > 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 com= > e > > across as intended, so to clarify the resulting native directories will b= > e: > > > > 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 wel= > l: > > > 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] --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
