harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: Supporting working on a single module?
Date Thu, 11 May 2006 16:24:42 GMT
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).

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.

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

-- 
Oliver Deakin
IBM United Kingdom Limited


---------------------------------------------------------------------
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


Mime
View raw message