harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "LvJimmy,Jing" <firep...@gmail.com>
Subject Re: [classlib]native codes layout question(was Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer)
Date Wed, 21 Jun 2006 07:20:39 GMT
Hi Oliver:

    I've seen the modularisation on native, that's great! :) But I have a
question here.
    As I work on native before, I usually build the whole native code once,
and then make seperate modules alone, e.g., luni, or nio. It was easy to
enter directory luni and force build by "make" and create a new DLL/so file.
In this way it is easy to write codes and debug. However after
modularisation nowadays, as there are envionment variables in the makefile,
which are defined in the build.xml, I have no idea but build whole native
with ant, even after changing a single line.
    So I turn to help for if there's an easy way to build single module
alone? Thanks!

at 06-6-20,Oliver Deakin <oliver.deakin@googlemail.com> 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.
>
> 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
>
> --
> 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
>
>


-- 

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message