Re: Supporting working on a single module?

[Oliver Deakin <ol...@googlemail.com>]

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.

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]),
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.

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

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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Re: Supporting working on a single module?

[Oliver Deakin <ol...@googlemail.com>]

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

-- 
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: Supporting working on a single module?

[Geir Magnusson Jr <ge...@pobox.com>]

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.

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.

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