* [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 an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.