You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Oliver Deakin <ol...@googlemail.com> on 2006/06/13 18:07:31 UTC
[classlib] Modularising the native code - it begins!
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
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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
Re: [classlib] Modularising the native code - it begins!
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Modularize on!
Oliver Deakin wrote:
> Geir Magnusson Jr wrote:
>> 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.
>>>
>>
>> Other than my outstanding objections to how HDK is being conflated with
>> the deploy directory, none :)
>>
>
> Notice I didn't mention the hdk at all in my previous mail ;)
>
>> I know I owe you some responses from last week, and that stuff shouldn't
>> stand in the way of what you want to do here.
>>
>
> Yes, our plans for the HDK are separate to what I'm doing here - this is
> purely about
> putting the native code under the modules directory.
>
>>
>>> 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 assume this is gradual - that you can do one module first, it can go
>> into SVN, and all still is fine?
>>
>
> That's exactly what I plan to do - small chunks that can be applied to SVN
> individually rather than one world changing event.
> I will take one module at a time (probably starting with prefs) and
> prepare a
> patch to move the native code that should be under that module into the
> right
> place, and alter all the necessary build scripts. Once that's ready, Ill
> raise a
> JIRA and attach the patch in the usual way, and then move onto the next
> module with a new patch and JIRA.
>
> Regards,
> Oliver
>
>
>>
>>> 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.
>>>
>>
>> Ooh! Ah! THanks!
>>
>> geir
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: [classlib] Modularising the native code - it begins!
Posted by Oliver Deakin <ol...@googlemail.com>.
Geir Magnusson Jr wrote:
> 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.
>>
>
> Other than my outstanding objections to how HDK is being conflated with
> the deploy directory, none :)
>
Notice I didn't mention the hdk at all in my previous mail ;)
> I know I owe you some responses from last week, and that stuff shouldn't
> stand in the way of what you want to do here.
>
Yes, our plans for the HDK are separate to what I'm doing here - this is
purely about
putting the native code under the modules directory.
>
>> 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 assume this is gradual - that you can do one module first, it can go
> into SVN, and all still is fine?
>
That's exactly what I plan to do - small chunks that can be applied to SVN
individually rather than one world changing event.
I will take one module at a time (probably starting with prefs) and
prepare a
patch to move the native code that should be under that module into the
right
place, and alter all the necessary build scripts. Once that's ready, Ill
raise a
JIRA and attach the patch in the usual way, and then move onto the next
module with a new patch and JIRA.
Regards,
Oliver
>
>> 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.
>>
>
> Ooh! Ah! THanks!
>
> geir
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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
Re: [classlib] Modularising the native code - it begins!
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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.
Other than my outstanding objections to how HDK is being conflated with
the deploy directory, none :)
I know I owe you some responses from last week, and that stuff shouldn't
stand in the way of what you want to do here.
>
> 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 assume this is gradual - that you can do one module first, it can go
into SVN, and all still is fine?
>
> 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.
Ooh! Ah! THanks!
geir
---------------------------------------------------------------------
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
Re: [classlib] Modularising the native code - it begins!
Posted by Oliver Deakin <ol...@googlemail.com>.
Hi all,
Here's another heads up to let you all know how it's going.
As you have probably noticed, I raised HARMONY-628 last week moving
the prefs code into its module. This patch has already been applied to
SVN head.
Earlier today I raised HARMONY-668 to move the launcher and vmls source
into the luni module.
Just in case anyone was wondering, the ordering of the native code I am
moving isn't (entirely) random. I'm working my way through the targets
in native-src/<platform>/makefile in the reverse order they need to be
built.
This provides me with gradual steps where I know all dependencies
will be built by the time my changes are reached.
I plan to move text, archive and auth next (into the text, archive and
auth modules,
respectively and somewhat unsurprisingly!). I will post again if I hit
any problems.
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
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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
Re: [classlib] Modularising the native code - it begins!
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/6/14, Mark Hindess <ma...@googlemail.com>:
>
> On 14 June 2006 at 7:24, Geir Magnusson Jr <ge...@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
Re: [classlib] Modularising the native code - it begins!
Posted by Gregory Shimansky <gs...@gmail.com>.
2006/6/14, Mark Hindess <ma...@googlemail.com>:
>
>
> On 14 June 2006 at 7:24, Geir Magnusson Jr <ge...@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
Re: [classlib] Modularising the native code - it begins!
Posted by Oliver Deakin <ol...@googlemail.com>.
Geir Magnusson Jr 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.
>
There was talk some time ago about possibly switching to gmake on all
platforms, and
using some of its capabilities to make picking up platform specific and
shared code a
simpler process. I'm not sure that any conclusion was ever reached in
that thread.
Perhaps its something that needs to be reexamined in the future.
>
>> 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.
>
In general with these things I'm also all in favour of sharing as much
as possible to keep
maintenance down.
I think that in this case, however, the duplication shouldn't have too
much impact. The two
makefile includes largely define directory locations, compiler flags and
generic compile lines
for each platform, and these shouldn't change very regularly.
Regards,
Oliver
> 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
>
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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
Re: [classlib] Modularising the native code - it begins!
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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
Re: [classlib] Modularising the native code - it begins!
Posted by Oliver Deakin <ol...@googlemail.com>.
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.
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?
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
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
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