harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy, Jing Lv" <firep...@gmail.com>
Subject Re: Supporting working on a single module?
Date Fri, 12 May 2006 05:59:08 GMT
 > Oliver Deakin wrote:
> Geir Magnusson Jr wrote:
>> Mark Hindess wrote:
>>> On 9 May 2006 at 10:32, Geir Magnusson Jr <geir@pobox.com> wrote:
>>>> Mark Hindess wrote:
>>>>> As the Harmony Classlib grows, I think that being able to work on a
>>>>> single module (or some subset of the modules) will become the
>>>>> typical way of working for many (perhaps even most) contributors.
>>>> Sure, that makes sense.
>>>>> So I think we need a plan to support this.  I also think that
>>>>> forcing ourselves to support this mode of working sooner rather than
>>>>> later will help us keep from accidentally breaking the modularity in
>>>>> the current build/development process.
>>>> Can you not work on a single module now?
>>> Yes.  But only by checking out everything.
>> Wouldn't you do that anyway?
>> I guess thats the mystery to me.  I figured that someone would do the 
>> full checkout, and go from there.
> I think it's good if we can cater not only for those developers who want 
> to completely checkout classlib trunk, but also for those who want to 
> work only on a single module. When I say "work on a single module", I 
> mean only checking that module's directory out of SVN, and not the code 
> for all the other modules, thereby saving download time and disk space, 
> not to mention the subsequent reduced build times of only recompiling a 
> single module.
> Currently a developer cannot work on both the native and Java code for a 
> module without checking out the whole of classlib trunk, because the 
> native source directories and Ant build script associated with them are 
> completely separate from the modules. IMHO it would be great if we could 
> get the build scripts and code repository layout into a state where a 
> developer can just checkout a module, grab an hdk from some location and 
> start changing and rebuilding both Java and native code (and also 
> running tests against the rebuilt libraries).

First of all, I shall give warm welcome to the refactor of native code. 
In fact when I want to touch native code, I download "native-source" and 
"depends" form svn, force a full build with ant using build.xml in 
native-source/. After that, when I modify some code in a certain part, 
e.g. luni, I change directory to luni and build that single module with 
"make" (or "nmake" in windows), in this way I get a new hyluni .DLL or 
.so file, copy it to harmony/deploy/deploy/jre/bin/ and restart VM. 
Separate them into modules would surely make it easy for developers.

> 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.
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. So, why not put them alone in a 
native directory as (it seems nearly the same with current)



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.

> 2) Alter the global build scripts to start creating an hdk under the 
> deploy directory, which contains a jdk which contains a jre. As Mark 
> described before, this hdk would probably look something like:
> deploy/hdk/
>               |--------jdk/
>               |              |-------jre/    (already being created at 
> the moment as deploy/jre)
>               |              +------include/    (already being created 
> at the moment as deploy/include)
>               |--------include/
>               +-------lib/
> The hdk/include directory would be much like the current 
> native-src/<platform>/include directories, and would contain a minimal 
> set of header files that define an interface between native modules. It 
> would be the responsibility of the individual module to copy its 
> required headers to this directory as a prerequisite for building.
> The hdk/lib directory would exist on Windows platforms, and would 
> contain .lib files for each native component.
> An hdk snapshot would then be a zip of the hdk directory, and should 
> provide everything necessary for a developer to build both native and 
> Java code against.
> 3) Modularise native and Java build scripts so that the individual 
> module's Ant scripts are capable of building native and Java source 
> against an hdk, rather than having its code compiled as part of a global 
> build. The rebuilt libraries would be placed back into the hdk 
> directory, so that the developers local hdk always contains their latest 
> built code (much as the current deploy/jre does).
> Additionally, I agree with Nathan [2] that allowing a developer working 
> in a modular way to run the entire test suite against their 
> work-in-progress code would be a good thing, and this could be done by 
> bundling tests and their resources in with an hdk.
> Regards,
> Oliver
> [1] 
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/%3cc3755b3a0602100609x1b79da6q@mail.gmail.com%3e

> [2] 
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/%3c000f01c673e2$92e74130$0e01a8c0@LITTLEGUY%3e



Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message