Mailinglist Archive: yast-devel (85 mails)
| < Previous | Next > |
Re: [yast-devel] ruby bindings
- From: Martin Vidner <mvidner@xxxxxxx>
- Date: Fri, 27 Jul 2007 13:59:59 +0200
- Message-id: <20070727115959.GA1694@xxxxxxxxxxxxxxxx>
Hi,
sorry for not reacting earlier, which I feel obliged to as the
maintainer of core and perl-bindings.
On Wed, Jul 25, 2007 at 11:59:10AM +0200, Duncan Mac-Vicar Prett wrote:
> On Wednesday 25 July 2007 11:41:42 Stefan Hundhammer wrote:
> > Having separate directories makes building and packaging a lot easier IMHO.
> > You also don't need to install all kinds of other language development
> > packages if you don't need a certain language. Also, different development
> > tools (autotools vs. cmake) make it hard to keep everything in one
> > directory, in particular since cmake builds out-of-source-tree and the
> > autotools inside the source tree.
Yes, these are the main arguments against grouping:
- different build dependencies
- different build systems [1]
> Yes, but also makes sharing code between the bindings impossible.
>
> For example, if you want to generate bindings for the libraries, the swig
> stuff will be the same for ruby and python.
First of all, perl-bindings and python-bindings should really be
named perl-bridge and python-bridge. (Hm, maybe I can still have them
renamed before 10.3.)
I understand the term "bindings" as an interface to *concrete*
functions, as seen in yast2-storage for example. That is what SWIG
does and where we could share code. But here we are building
*generic* bridges to any function. From what I have seen, ruby has
had some bindings too and now Duncan built a bridge.
AFAIK, there is no code sharing between the bridges, so that is
another argument for keeping them separate.
[1]: perl-bindings additionally includes an interface between
automake and Perl MakeMaker, but that is not really a complication
--
Martin Vidner, not a bridge player ♣♦♥♠
http://en.opensuse.org/User:Mvidner
Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx
sorry for not reacting earlier, which I feel obliged to as the
maintainer of core and perl-bindings.
On Wed, Jul 25, 2007 at 11:59:10AM +0200, Duncan Mac-Vicar Prett wrote:
> On Wednesday 25 July 2007 11:41:42 Stefan Hundhammer wrote:
> > Having separate directories makes building and packaging a lot easier IMHO.
> > You also don't need to install all kinds of other language development
> > packages if you don't need a certain language. Also, different development
> > tools (autotools vs. cmake) make it hard to keep everything in one
> > directory, in particular since cmake builds out-of-source-tree and the
> > autotools inside the source tree.
Yes, these are the main arguments against grouping:
- different build dependencies
- different build systems [1]
> Yes, but also makes sharing code between the bindings impossible.
>
> For example, if you want to generate bindings for the libraries, the swig
> stuff will be the same for ruby and python.
First of all, perl-bindings and python-bindings should really be
named perl-bridge and python-bridge. (Hm, maybe I can still have them
renamed before 10.3.)
I understand the term "bindings" as an interface to *concrete*
functions, as seen in yast2-storage for example. That is what SWIG
does and where we could share code. But here we are building
*generic* bridges to any function. From what I have seen, ruby has
had some bindings too and now Duncan built a bridge.
AFAIK, there is no code sharing between the bridges, so that is
another argument for keeping them separate.
[1]: perl-bindings additionally includes an interface between
automake and Perl MakeMaker, but that is not really a complication
--
Martin Vidner, not a bridge player ♣♦♥♠
http://en.opensuse.org/User:Mvidner
Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx
| < Previous | Next > |