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: [classlib] Modularising the native code - it begins!
Date Thu, 15 Jun 2006 10:55:01 GMT

On 14 June 2006 at 16:45, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> Mark Hindess wrote:
> <snip>
> > On 14 June 2006 at 7:24, Geir Magnusson Jr <geir@pobox.com> wrote:
> >   
> >> Oliver Deakin wrote:
> >>     
> >>> 2) The makefiles for each native component include two files
> >>> (defines.mak and rules.mak on windows and makefile.include
> >>> and rules.mk on linux) that are generic across all components.
> >>>
> >>> The question is: where should these common files be located once
> >>> the natives are moved into the modules?
> >>>
> >>> At the moment, I can't really see an obvious location where all modules
> >>> could access them.
> >>> The only option I've thought of so far is to have one copy of the files
i
> n
> >>> each module that contains native code (so that would be one copy in
> >>> each of archive, auth, luni, prefs and text). The files would be located
> >>> under
> >>> /modules/<modulename>/src/main/native, and shared by all the
> >>> native components under that module.
> >>> Any preferences/ideas about this?
> >>>       
> >> I think that works.  I've been having similar thoughts about this re
> >> drlvm, and have been using the classlib make config as a reference.  I'm
> >> trying to limit the amount of duplicated things because I'm slothful and
> >> lazy and don't want to maintain them.
> >>     
> >
> > I'd rather not maintain lots of copies.  Could we not keep the shared
> > parts in the deploy (I was tempted to say hdk) somehow?  It's might
> > sound a little crazy but actually given that we want modules to be
> > consistent with other compiled artifacts it's actually quite useful to
> > have common structure, variable and compile flag settings.
> >   
> 
> I would also prefer if we could find a good central place to keep these 
> rather than many copies -
> do you have any suggestions?

In the support sub-directory?  The support tree is already required
by most (all?) modules.  I renamed the originally contributed
'test_support' tree to support since I figured we might have other
support files.  For example java code for ant tasks if the build gets to
hard to manage with basic ant.

-Mark





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