harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: [classlib] Modularising the native code - it begins!
Date Wed, 14 Jun 2006 13:53:51 GMT
2006/6/14, Mark Hindess <mark.hindess@googlemail.com>:
>
> 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

+1 for not having lots of copies

Mikhail

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

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