* Duncan Mac-Vicar Prett <dmacvicar@suse.de> [Dec 21. 2007 10:28]:
On Friday 21 December 2007 10:06:02 Klaus Kaempf wrote:
Yes, in some parts. The problem with generating from sat-solvers .h files is the vast amount of internal data being exposed.
We can include the .h files and then add ignore statements to the swig .i file. I guess the amount of things we expose is bgger than the amount of things we want to hide or?
No, its not. Just look at the amount of structure properties in a typical sat solver .h file. I'd rather add specific accessor methods instead of lots of %ignores ;-)
Why did you change cxx to .c when the output is actually a C++ source (the OO layer is inlined) Whats the value of having C++ here ? Please explain.
Oh, SWIG does not generate OO libraries from C APIs for free. I define C++ classes in the .i file which wrap the C methods. Swig parses those classes and generate ruby classes on the fly. Otherwise I would need to have a swig generated C api in ruby and wrap them in ruby code (and have a hybrid extension).
Huh ? I don't understand the part of wrapping in Ruby code. Have a look at the current satsolver.i file and the examples in ruby/tests. I think its pretty straightforward. Adding C++ classes seems more complex to me. But I'm open to any counterexamples ... :-P Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org