From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC] python bindings handling
Date: Thu, 2 Feb 2012 23:24:55 +0100 [thread overview]
Message-ID: <20120202232455.03a07aaa@skate> (raw)
In-Reply-To: <878vkk9auh.fsf@macbook.be.48ers.dk>
Le Thu, 02 Feb 2012 22:36:22 +0100,
Peter Korsgaard <jacmet@uclibc.org> a ?crit :
> Thomas> I think I would say 2. It's not because you have Python
> Thomas> *and* you have some library that you necessarily want the
> Thomas> binding for that lib. Just make those bindings new Python
> Thomas> packages (in the new Python menu you created!) and that
> Thomas> should be good. No?
>
> So you're suggesting to put those BR2_ options in seperate Config.in
> files and source them under the Python menu? Hmm, I'm not sure I like
> that. Aren't most python bindings very small compared to python / the
> libraries they provide bindings for? If so, I think option 1 is nicer
> (similar to how we E.G. handle optional openssl support in lots of
> places).
Ah, then I think I misunderstood. I think those Python bindings were a
*separate* package from the C/C++ library for which the binding is
designed, i.e that you had two packages:
libfoo
python-libfoo
In which case I think python-libfoo (which is a separate package)
should go in the Python section.
In the other case (i.e, the binding is directly an option in the C/C++
library itself and both are a single package in terms of upstream
source), then yeah, option 1/ would probably be good.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2012-02-02 22:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-27 15:02 [Buildroot] [RFC] python bindings handling Yegor Yefremov
2012-01-27 15:53 ` Thomas Petazzoni
2012-01-27 15:55 ` Yegor Yefremov
2012-02-02 21:36 ` Peter Korsgaard
2012-02-02 22:24 ` Thomas Petazzoni [this message]
2012-02-02 22:26 ` Peter Korsgaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120202232455.03a07aaa@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox