2006/6/14, Mark Hindess <[EMAIL PROTECTED]>:

On 14 June 2006 at 7:24, Geir Magnusson Jr <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to