Mailinglist Archive: zypp-devel (56 mails)

[Klaus Kaempf <kkaempf@xxxxxxx>]

* Duncan Mac-Vicar Prett <dmacvicar@xxxxxxx> [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@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx