harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [classlib] Modularising the native code - it begins!
Date Wed, 14 Jun 2006 11:24:48 GMT


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.

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

geir

> 
> Regards,
> Oliver
> 
> 
> Oliver Deakin wrote:
>> Hi all,
>>
>> As you have probably noticed, I recently raised HARMONY-596
>> (which Mark has already kindly applied) to make .lib and .a files
>> generate
>> straight into the deploy/lib directory.
>>
>> I think that now we are in a position to finally modularise the
>> classlib native
>> code. I've volunteered to do this, and plan to move the code down into
>> the
>> modules in the layout described in [1], since I believe there were no
>> objections.
>>
>> I will probably warm up with some of the "easier" modules -
>> prefs/text/auth
>> - before moving onto archive and luni. Ill raise a separate JIRA for each
>> set of moves, and let you all know how I progress and if there are any
>> problems/questions I have.
>>
>> I also plan to create a doc for the website describing the location of
>> the native
>> code, and summarising how platform specific and shared code is laid out
>> within each native component.
>>
>> Please let me know if there are any issues with this - otherwise I will
>> continue to work on it and submit patches.
>>
>> Regards,
>> Oliver
>>
>> [1]
>> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/%3c4463654A.3080105@googlemail.com%3e
>>
>>
> 


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