harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: Supporting working on a single module?
Date Fri, 12 May 2006 07:41:16 GMT

On 12 May 2006 at 13:59, "Jimmy, Jing Lv" <firepure@gmail.com> 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.


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