Mailinglist Archive: zypp-devel (56 mails)
| < Previous | Next > |
Re: [zypp-devel] Re: [zypp-commit] r8131 - in /trunk/sat-solver/bindings: ruby/CMakeLists.txt ruby/ruby.i ruby/satsolver.rb ruby/tests/ ruby/tests/loading.rb ruby/tests/pool.rb ruby/tests/repo.rb satsolver.i
- From: Duncan Mac-Vicar Prett <dmacvicar@xxxxxxx>
- Date: Fri, 21 Dec 2007 10:29:02 +0100
- Message-id: <200712211029.02901.dmacvicar@xxxxxxx>
On Friday 21 December 2007 10:06:02 Klaus Kaempf wrote:
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?
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).
Duncan
--
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
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?
Why did you change cxx to .c when the output is actually a C++ sourceWhats the value of having C++ here ? Please explain.
(the OO layer is inlined)
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).
Duncan
--
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
| < Previous | Next > |