harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [classlib]native codes layout question(was Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer)
Date Fri, 23 Jun 2006 07:02:26 GMT
FYI, I've raised Harmony-646 and applied patch for this.

Oliver Deakin wrote:
> Paulex Yang wrote:
>> Oliver Deakin wrote:
>>> Paulex Yang wrote:
>>>> Seems no one objects this proposal:), so I'm going to implement the 
>>>> JNI1.4 enhancement in nio module, i.e, provide patch to 
>>>> Harmony-578, Because this implementation requires some native 
>>>> codes, so I probably need to reintroduce hynio.dll(.so), but I have 
>>>> some questions.(Excuse me about my ignorance on the native layout 
>>>> evolution).
>>>> At first, seems native codes will be separated into modules(I guess 
>>>> Oli is working on?), so should I assume my native codes will be 
>>>> directly put into nio modules, or still in native-src/win.IA32/nio 
>>>> directory? because I'm used to provide a shell to move/svn add new 
>>>> files in the patch, so it will be easier for me to know how others 
>>>> think about it.
>>> It depends on whether you want to wait for what I'm doing or not :)
>>> If you want to get the code out now, then you can temporarily put it 
>>> under native-src/win.IA32/nio and I will move it later as part of 
>>> the natives modularisation.
>>> However, if you don't mind waiting a day or so I should be able to 
>>> submit my first patch to move the prefs natives. This ought to be 
>>> enough of an example for you to put your native code directly into 
>>> modules/nio/src/main/native.
>>>> And second, the native codes probably need portlib, so the 
>>>> portlib's header file must be accessible, say, portsock.h, but now 
>>>> it has been moved into luni/src/main/native/blabla, should I 
>>>> include one in my patch so that nio module can have a copy? or the 
>>>> header file itself should be put some other well known 
>>>> directory(deploy/build/include I guess)?
>>> At build time, the "copy.native.includes" target in 
>>> luni/make/build.xml is called - it copies a selection of the header 
>>> files in luni/src/main/native/include that need to be shared between 
>>> modules into the deploy/include directory. This is done with an 
>>> explicit fileset in luni/make/build.xml - if you need to have 
>>> portsock.h added to the list of shared header files, then this is 
>>> the place to make that change. Just add its filename to the list, 
>>> and next time you build it will appear in the deploy/include 
>>> directory. Your nio code should include the headers from the 
>>> deploy/include dir, and *not* directly from the 
>>> luni/src/main/native/include dir.
>> Oli, I tried to modify the luni/make/build.xml, and it successfully 
>> copied the portsock.h, but I found I still cannot build my native 
>> codes. So I looked inside the portsock.h, and found that all its 
>> content is just to include another file: "../port/hysock.h", my 
>> native codes in modules/nio/src/main/native cannot find 
>> "../port/hysock.h" so it fails. I guess the reason why the luni 
>> natives still can build is all LUNI's native codes are still located 
>> in native-src/luni, so they can found the hysock.h in native-src/port.
>> Seems portsock.h is useless and confusable, so I suggest the steps 
>> below to fix this problem:
>> 1. svn delete portsock.h in luni
>> 2. svn move hysock.h from native-src to luni
>> 3. update all reference to portsock.h to hysock.h
>> 4. rebuild
> Yes, that sounds reasonable. From what I can see portsock.h is basically
> pointless, since it just includes hysock.h. Your plan to replace
> portsock.h with hysock.h sounds like the right thing to do here.
>> If no one objects, I'll raise a separated JIRA and provide patch
> Thanks!
> Regards,
> Oliver
>>> I hope this makes more sense now - if it doesn't, please let me 
>>> know. I am in the process of writing up some documentation for the 
>>> website on the natives layout and where headers should go (and also 
>>> how modules should build against the HDK) - once that is complete it 
>>> should all be a lot clearer.
>>> Regards,
>>> Oliver

Paulex Yang
China Software Development Lab

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

View raw message