* [Buildroot] [RFC] python bindings handling
@ 2012-01-27 15:02 Yegor Yefremov
2012-01-27 15:53 ` Thomas Petazzoni
0 siblings, 1 reply; 6+ messages in thread
From: Yegor Yefremov @ 2012-01-27 15:02 UTC (permalink / raw)
To: buildroot
How should we handle Python and other bindings?
1. check if Python etc is selected and enable them automatically?
2. make an option per package containing bindings
3. something else
Yegor
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [RFC] python bindings handling
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
0 siblings, 2 replies; 6+ messages in thread
From: Thomas Petazzoni @ 2012-01-27 15:53 UTC (permalink / raw)
To: buildroot
Le Fri, 27 Jan 2012 16:02:54 +0100,
Yegor Yefremov <yegorslists@googlemail.com> a ?crit :
> How should we handle Python and other bindings?
>
> 1. check if Python etc is selected and enable them automatically?
> 2. make an option per package containing bindings
> 3. something else
I think I would say 2. It's not because you have Python *and* you have
some library that you necessarily want the binding for that lib. Just
make those bindings new Python packages (in the new Python menu you
created!) and that should be good. No?
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [RFC] python bindings handling
2012-01-27 15:53 ` Thomas Petazzoni
@ 2012-01-27 15:55 ` Yegor Yefremov
2012-02-02 21:36 ` Peter Korsgaard
1 sibling, 0 replies; 6+ messages in thread
From: Yegor Yefremov @ 2012-01-27 15:55 UTC (permalink / raw)
To: buildroot
Am 27.01.2012 16:53, schrieb Thomas Petazzoni:
> Le Fri, 27 Jan 2012 16:02:54 +0100,
> Yegor Yefremov <yegorslists@googlemail.com> a ?crit :
>
>> How should we handle Python and other bindings?
>>
>> 1. check if Python etc is selected and enable them automatically?
>> 2. make an option per package containing bindings
>> 3. something else
>
> I think I would say 2. It's not because you have Python *and* you have
> some library that you necessarily want the binding for that lib. Just
> make those bindings new Python packages (in the new Python menu you
> created!) and that should be good. No?
Yes. It looks good.
Yegor
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [RFC] python bindings handling
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
1 sibling, 1 reply; 6+ messages in thread
From: Peter Korsgaard @ 2012-02-02 21:36 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Thomas> Le Fri, 27 Jan 2012 16:02:54 +0100,
Thomas> Yegor Yefremov <yegorslists@googlemail.com> a ?crit :
>> How should we handle Python and other bindings?
>>
>> 1. check if Python etc is selected and enable them automatically?
>> 2. make an option per package containing bindings
>> 3. something else
Thomas> I think I would say 2. It's not because you have Python *and* you have
Thomas> some library that you necessarily want the binding for that lib. Just
Thomas> make those bindings new Python packages (in the new Python menu you
Thomas> created!) and that 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).
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [RFC] python bindings handling
2012-02-02 21:36 ` Peter Korsgaard
@ 2012-02-02 22:24 ` Thomas Petazzoni
2012-02-02 22:26 ` Peter Korsgaard
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Petazzoni @ 2012-02-02 22:24 UTC (permalink / raw)
To: buildroot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [RFC] python bindings handling
2012-02-02 22:24 ` Thomas Petazzoni
@ 2012-02-02 22:26 ` Peter Korsgaard
0 siblings, 0 replies; 6+ messages in thread
From: Peter Korsgaard @ 2012-02-02 22:26 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Thomas> Ah, then I think I misunderstood. I think those Python bindings were a
Thomas> *separate* package from the C/C++ library for which the binding is
Thomas> designed, i.e that you had two packages:
Thomas> libfoo
Thomas> python-libfoo
Thomas> In which case I think python-libfoo (which is a separate package)
Thomas> should go in the Python section.
Yes, if it is a seperate package upstream, then I agree.
Thomas> In the other case (i.e, the binding is directly an option in
Thomas> the C/C++ library itself and both are a single package in terms
Thomas> of upstream source), then yeah, option 1/ would probably be
Thomas> good.
Great!
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-02-02 22:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2012-02-02 22:26 ` Peter Korsgaard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox