Re: [Vala] enum typing



It doesn't.. I put together an autoconf macro script to determine the library/include paths.. As well as the libraries to link against as they differ from release to release and installation type. The wrapper interface will include pkgconfig and obviously be more Vala friendly.. That is, if I do it well.


On Jun 26, 2009, at 11:37 PM, Yu Feng <rainwoodman gmail com> wrote:

BTW: if there is a pkgconfig file for oci, please make sure the main
vapi file's name (the one that pulls in all dependencies) matches
the .pc file's name.

Otherwise `valac --pkg oci your-program.vala' won't work.

Yu
On Fri, 2009-06-26 at 22:39 -0600, Shawn Ferris wrote:

Now, in the Vapi, I could do this to type args: (HType being the enum in
this case)

 public int HandleFree (
       void*              handlp,
       HType              type
 );

so, I'm not sure what the difference really is?

looks like you triggered a bug in valac about defualt property values of
non-native types.

I wondered if I hadn't.. I'll file a bug report

Also, I was curious about separating api's into multiple vapi.. For
instance, the oracle one is huge, if I ever get to the point that the entire thing is impletement (unlikely) but, to make it easy for myself, I created oci_enums.vapi, oci_structs.vapi and oci.vapi for everthing that doesn't fit in structs and enums.. Then I used oci.deps to pull in structs and enums.. is that a good idea, or should the final product be
a single concatenated view of the three?


did you consider the possibility splitting the API into files by
functionality?

I hadn't considered that actually.. but, the more I thought about it,
it's only used during the compile, so I'm not sure it matters one way or the other.. but, if I were to install the oci.vapi file into the system vapi directory, I'm guessing one file would be preferred and that can be
easilly handled through the makefiles.

Thanks Yu!

SMF





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]