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 Wed, 14 Jun 2006 13:47:30 GMT

On 14 June 2006 at 7:24, Geir Magnusson Jr <geir@pobox.com> wrote:
> 
> Oliver Deakin wrote:
> > I have a couple of questions about location of makefiles and makefile
> > includes
> > 
> > 1) Currently the makefiles for the modules are stored underneath the
> > platform
> > and component they relate to. For example, the luni makefiles are situated
> > at native-src/linux.IA32/luni/makefile and
> > native-src/win.IA32/luni/makefile.
> > 
> > Once I move the luni native code into the luni module, its code
> > layout will look like:
> > 
> > modules/luni/src/main/native/luni/
> >                               |---shared
> >                               |---linux
> >                               \---windows
> > 
> > But where should the platform specific makefiles go?
> > 
> > I think we have two choices here - put the linux one in the linux dir,
> > and similar for the windows version (as it is now), or put them both
> > under the modules/luni/src/main/native/luni/ directory and rename them
> > something like makefile.linux and makefile.windows.
> > 
> > Personally Im happy to go with the first option and keep each makefile
> > under its corresponding platform directory until we have reason
> > to change it. Just thought Id gauge if anyone has any preference.
> 
> I agree.  I'm also wondering how painful it would be to switch to
> something other than NMAKE as it seems pretty braindead.

I agree.  Besides it's quite easy to change later - if we find something
better than nmake for instance.  (I loathe nmake because it doesn't even
have some of the most trivial features for variable manipulation.)  I 
did try using the mingw toolset but didn't get very far but I'll try 
looking at it when we are modularised - one module at a time.

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

(Aside: The linux kernel used to do something like this with a 
Rules.make file that you included.  Now they do it slightly differently
where you set a variable pointing to your module source and use the
standard kernel Makefile from the built source tree like:

  make -C <kernel-source-dir> M=$PWD modules modules_install

I quite like this since it ensures consistency.)

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