On 12 May 2006 at 13:59, "Jimmy, Jing Lv" <[EMAIL PROTECTED]> wrote: > Oliver Deakin wrote: > > > > 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) > > > > Additionally, each module may have an include directory that > > contains header files required across its native components. Each > > native component would contain subdirectories for its shared and > > platform specific code. > > If I do not misunderstand the chart I'm afraid combining native and > java code into one module would not be a good idea, specially for > module Luni. It IS very large now, and become much larger if we do so, > thus it may spend long time to download from SVN.
The native code is relatively small compared to the size of the java code. So I don't really think download from svn should be a big issue. For example, modules/luni is around 36M where the sum of the natives that will go in to modules/luni is around 3.5M. > What's more important, many user may care nothing about the native > code, they only want to read or modify the java code. Add native code > to the module would be an encumbrance to them. I don't think it should be such an encumbrance. The problems at the moment are: 1) We always clean and build natives where as we do incremental build (within a module) for java code. This makes a big difference. For example, if, after a full build, I change directory to native-src/linux.ia32, touch one C file in thread, and then type "make" it takes 7 seconds to build. Even this is too long because of ... 2) We do too much linking for any *.so/*.dll change - lots of additional linking is done because of an "error" in the dependencies - things depend on the *.so/*.dll files where as they could depend only on the header files. We can fix this but it will be easier when we've moved the natives. 3) Recursive make. Again we could fix this now but it would be easier to fix after moving to modules. If it's still too slow after we've fixed these, then maybe we could split build target to build.java and build.natives. But I don't think we should need to; once you remove recursive make checking dependencies when there is nothing to do is very fast with make - at least as fast as it is with javac and there is significantly less C code. > So, why not put them alone in a native directory as (it seems nearly > the same with current) > > +------zlib/ > modules/native/auth/src/ > +-------auth/ > > modules/native/luni/src/ > |--------common/ > |--------fdlibm/ > ... > > and alter build scripts? Perhaps only scripts are important to rewrite. > If I am right, what we really need is: we can download one single module > native source, e.g., Luni, and all other stubs, libs, DLL/so files or > something, then modify Luni native source, and build them all and create > a new hyluni.dll/so. In this way we no longer need to download other > source code besides Luni but still get a success build. I'd rather have the simplicity of having everything for a module in one tree and fix the problems that make this appear to be a burden. Regards, Mark. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
