You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2006/06/14 15:47:30 UTC
Re: [classlib] Modularising the native code - it begins!
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
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
Re: [classlib] Modularising the native code - it begins!
Posted by Oliver Deakin <ol...@googlemail.com>.
Tim Ellison wrote:
> Oliver Deakin wrote:
>
>> Tim Ellison wrote:
>>
>>> Oliver Deakin wrote:
>>> <snip>
>>>
>>>
>>> move them out to the tools/launcher directory where they better belong.
>>>
>> So, with the removal of these Harmony internal files from depends, that
>> directory becomes external
>> dependencies only again, meaning we shouldn't put the makefile includes
>> there?
>>
>
> As Geir wrote elsewhere, it makes sense to share all resources at the
> appropriate level within the project, so if the makefile rules are to be
> used by drlvm as well as classlib then they would find a home in the
> /dependencies (or whatever it is called) that is a peer of them. If it
> makes sense that the rules are classlib wide then put them in
> classlib/depends (or whatever) and so on. The actual dir names are open
> for debate.
>
Currently these includes are only used by classlib, and I dont know of
any plans to
adopt them in any of the Harmony VMs, so I think they should go under
classlib/trunk/depends, in a new "build" directory.
Ill put together a patch that will move these includes to the
depends/build dir,
alter the build system to copy them into a shared place in deploy (probably
deploy/build) and update the makefiles for all components to pick them up
from there.
These files will need to be made part of the HDK when we start producing
them,
since they will not be stored in any particular module but will be
required by
all modules with native code.
Regards,
Oliver
> Regards,
> Tim
>
>
--
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 Tim Ellison <t....@gmail.com>.
Oliver Deakin wrote:
> Tim Ellison wrote:
>> Oliver Deakin wrote:
>> <snip>
>>
>>> but now that I look at it
>>> I see that the
>>> depends/files dir contains the Harmony properties files, so maybe I'm
>>> wrong.
>>
>> Those are launcher-specific, so don't get too attached to them, I'll
>
> I'll try.. ;)
> It looks like the .properties files contain some messages for the port
> lib and zip, which I guess
> will need to be split out and put into their respective native components.
>
>> move them out to the tools/launcher directory where they better belong.
>
> So, with the removal of these Harmony internal files from depends, that
> directory becomes external
> dependencies only again, meaning we shouldn't put the makefile includes
> there?
As Geir wrote elsewhere, it makes sense to share all resources at the
appropriate level within the project, so if the makefile rules are to be
used by drlvm as well as classlib then they would find a home in the
/dependencies (or whatever it is called) that is a peer of them. If it
makes sense that the rules are classlib wide then put them in
classlib/depends (or whatever) and so on. The actual dir names are open
for debate.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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>.
Tim Ellison wrote:
> Oliver Deakin wrote:
> <snip>
>
>> but now that I look at it
>> I see that the
>> depends/files dir contains the Harmony properties files, so maybe I'm
>> wrong.
>>
>
> Those are launcher-specific, so don't get too attached to them, I'll
>
I'll try.. ;)
It looks like the .properties files contain some messages for the port
lib and zip, which I guess
will need to be split out and put into their respective native components.
> move them out to the tools/launcher directory where they better belong.
>
So, with the removal of these Harmony internal files from depends, that
directory becomes external
dependencies only again, meaning we shouldn't put the makefile includes
there?
Regards,
Oliver
> Regards,
> Tim
>
>
>
--
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 Tim Ellison <t....@gmail.com>.
Oliver Deakin wrote:
<snip>
> but now that I look at it
> I see that the
> depends/files dir contains the Harmony properties files, so maybe I'm
> wrong.
Those are launcher-specific, so don't get too attached to them, I'll
move them out to the tools/launcher directory where they better belong.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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>.
Mark Hindess wrote:
<snip>
> On 14 June 2006 at 7:24, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>> Oliver Deakin wrote:
>>
>>> 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
> 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.
>
I would also prefer if we could find a good central place to keep these
rather than many copies -
do you have any suggestions?
If we copy them into deploy at build time (similar to how we copy in the
headers) then we
just need to pick a place for them to live before they are copied.
Putting them under depends didn't quite feel right to me at first - I
thought the depends directory
was intended to contain external dependencies, but now that I look at it
I see that the
depends/files dir contains the Harmony properties files, so maybe I'm
wrong. If that's the case,
then perhaps they could go in a separate directory under depends?
Alternatively, they could go into a subdir of /make, but I like that less.
Thoughts?
Regards,
Oliver
> (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
>
>
>
--
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>.
Mark Hindess wrote:
> (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.)
Can nmake.exe support this?
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,
I have just raised HARMONY-744 which moves the vmi and luni native
code into the luni module, and the zip and zlib code into archive.
AFAICS, there is only one more set of moves to do before native
modularisation is complete (phew!).
With the last set of changes, I plan to move the native-src/build.xml into
the top level make dir and call it build-native.xml (to fit in with
build-java.xml
and build-test.xml).
If anyone has any objections, please let me know.
Regards,
Oliver
--
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