Geir Magnusson Jr wrote:
Oliver Deakin wrote:
Just thought Id give a bit of a heads up on HARMONY-561.
The patch attached to that JIRA moves the header files under the
native-src/<platform>/include directories into
/modules/<luni|archive>/src/main/native. It also updates the build
scripts and
makefiles to move the headers into a shared location (<hdk>/include, as
described at [1]) and compile against their new location.
Right, and I really don't like it, have been saying I don't like
overwriting the HDK, gave a reason for why I don't like it, and never
heard a reason why it must be this way.
ok, I understand that - perhaps I should have used deploy/include
instead of <hdk>/include
in the above description, but I was trying to link the patch with the
HDK layout described
on the website so it was clear how it would enable us to create and use
an HDK.
The patches Im submitting at the moment are *not* intended to overwrite
a base HDK (which
I believe is what you did not like), but rather to place their output in
the working deploy
directory.
What Im currently doing is just attempting to modularise the native code
with building against
an HDK in mind. This does *not* preclude your suggestion of having an
immutable base HDK -
in fact, I hope that the work Im doing will enable us to do exactly
that. However, before
that can happen there is plenty of work to be done reorganising the
natives and making
the build scripts capable of building against an HDK.
In summary, here's what IMHO still needs to be done with the natives to
get the HDK use
that we have discussed:
1) Reorganise natives into modules (this has been hanging over us for
too long!)
2) Alter the build scripts to be capable of building in a modular way
(Java and native code)
against the contents of the deploy (or target) directory.
3) Finally, alter the build scripts to be capable of building against a
base HDK that
is immutable (i.e. your suggestion) but still putting its produced
binaries into the deploy
directory (so not overwriting the base HDK content).
Does that sound good?
If you want me to put my money where my mouth is and just patch it, I'm
more than able to do that, but I'd rather reach consensus together on
how to go forward.
Agreed - concensus is preferable and Im glad you brought up the fact
that you were unhappy
with what was happening and gave me an opportunity to explain. Id like
the HDK to be
satisfactory and useful to all participants in the project.
Regards,
Oliver
The next piece of work I intend to look at is getting the windows/linux
makefiles to
build their .lib/.a files directly into the <hdk>/lib directory (also
described in [1]),
See above
and getting each native component to link against the libs at that
location. Once
this is done the deploy directory should look like a complete HDK after
a global
build. ie it will contain everything needed to build each individual
native component
or java module against it.
That is a good outcome if it isn't the hdk directory. If it's the HDK
directory, consider me against it.
We should then be able to make the final moves of the classlib native code
into the modules (and start creating some classlib HDK snapshots).
Great.
geir
Regards,
Oliver
[1] http://incubator.apache.org/harmony/subcomponents/classlibrary/hdk.html
---------------------------------------------------------------------
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]
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
