harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Shimansky" <gshiman...@gmail.com>
Subject Re: [classlib] Modularising the native code - it begins!
Date Wed, 14 Jun 2006 14:36:14 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.
>

Also if we decide to go with gmake then later we may add a configure script
to find dependencies like apr, icu, icu4j, log4cxx, zlib and others provided
by the system installation instead of downloading them.

-- 
Gregory Shimansky, Intel Middleware Products Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message