Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 202.81.18.155 is neither permitted nor
 denied by domain of paulex.yang@gmail.com)
Message-ID: <449B9202.7060206@gmail.com>
Date: Fri, 23 Jun 2006 15:02:26 +0800
From: Paulex Yang <paulex.yang@gmail.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib]native codes layout question(was Re:
 [classlib][NIO|VMI]JNI
 1.4 enhancement on ByteBuffer)
References: <448EA04B.3060000@gmail.com> <448EBADE.3000001@dellroad.org>
 <448F7CAD.9090009@gmail.com> <44900C72.90007@dellroad.org>
 <4490F3F7.9000904@gmail.com> <44979333.2000500@gmail.com>
 <4497BB0D.3090800@googlemail.com> <449A57A7.90709@gmail.com>
 <449A766E.8060604@googlemail.com>
In-Reply-To: <449A766E.8060604@googlemail.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=gb18030; format=flowed

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
IBM


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