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 > _______________________________________________ Vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
