| Message ID | 1368158558-6069-2-git-send-email-spenser@gillilanding.com |
|---|---|
| State | Superseded |
| Headers | show |
Hi Spenser, Very quick first review... First of all, a comment that is not so much directed at you but at the rest of the BR developers: the naming issue. We have a tendency to make a copy of a package when there is a major version change, cfr. python3 and qt5. However, in this case, I don't think it's a good idea. At this time, many (most?) gstreamer downstreams have already moved to 1.x. Also, no more patches will be made the the 0.10 series (though distro's may still make patches). So we can expect the old gstreamer stuff to die out relatively quickly. But if we call the new thing gstreamer1 now, we're essentially stuck with that name for all eternity. So instead I'd try to make 0.10 or 1.0 a choice in the gstreamer package itself. For me it's fine if inside the Config.in and the .mk files we basically have the two versions in a big ifeq() construct, but at least we can keep on using the BR2_PACKAGE_GST* symbols. Obviously, there will be some packages that break down when gstreamer 1.0 is used, but we'll have to discover that at some point anyway. On 10/05/13 06:02, Spenser Gilliland wrote: > This patch adds the gstreamer version 1.x series to buildroot. > > Signed-off-by: Spenser Gilliland <spenser@gillilanding.com> > --- > package/multimedia/Config.in | 1 + > package/multimedia/gstreamer1/Config.in | 37 +++++++++++++++++++++++++++ > package/multimedia/gstreamer1/gstreamer1.mk | 36 ++++++++++++++++++++++++++ > 3 files changed, 74 insertions(+) > create mode 100644 package/multimedia/gstreamer1/Config.in > create mode 100644 package/multimedia/gstreamer1/gstreamer1.mk > > diff --git a/package/multimedia/Config.in b/package/multimedia/Config.in > index 931e6d3..f6a5fd7 100644 > --- a/package/multimedia/Config.in > +++ b/package/multimedia/Config.in > @@ -6,6 +6,7 @@ source "package/multimedia/faad2/Config.in" > source "package/multimedia/flac/Config.in" > source "package/multimedia/ffmpeg/Config.in" > source "package/multimedia/gstreamer/Config.in" > +source "package/multimedia/gstreamer1/Config.in" > source "package/multimedia/gst-ffmpeg/Config.in" > source "package/multimedia/gst-dsp/Config.in" > source "package/multimedia/gst-fsl-plugins/Config.in" > diff --git a/package/multimedia/gstreamer1/Config.in b/package/multimedia/gstreamer1/Config.in > new file mode 100644 > index 0000000..b1fd8b1 > --- /dev/null > +++ b/package/multimedia/gstreamer1/Config.in > @@ -0,0 +1,37 @@ > +config BR2_PACKAGE_GSTREAMER1 > + bool "gstreamer1" > + depends on BR2_USE_WCHAR # glib2 > + depends on BR2_TOOLCHAIN_HAS_THREADS > + select BR2_PACKAGE_LIBGLIB2 > + help > + GStreamer is an open source multimedia framework. > + > + http://gstreamer.freedesktop.org/ > + > +config BR2_PACKAGE_GSTREAMER1_GST_DEBUG > + bool "enable gst-debug trace support" > + default y > + depends on BR2_PACKAGE_GSTREAMER1 We nowadays prefer to put sub-options inside an if...endif construct instead of with 'depends on'. Regards, Arnout > + help > + Enable support for the gst-debug tracing functionality in gstreamer. > + This has limited CPU overhead, but does increase the rootfs size > + somewhat. > + > +config BR2_PACKAGE_GSTREAMER1_PLUGIN_REGISTRY > + bool "enable plugin registry" > + default y > + depends on BR2_PACKAGE_GSTREAMER1 > + help > + Enable support for the GStreamer plugin registry. This may increase > + the launch-time for a GStreamer application. > + > +config BR2_PACKAGE_GSTREAMER1_INSTALL_TOOLS > + bool "install gst-launch gst-inspect" > + default y > + depends on BR2_PACKAGE_GSTREAMER1 > + help > + Install the gst-launch and gst-inspect tools. This will take up > + additional space on the target > + > +comment "gstreamer requires a toolchain with WCHAR and threads support" > + depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS [snip]
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
Arnout> Hi Spenser,
Arnout> Very quick first review...
Arnout> First of all, a comment that is not so much directed at you but at
Arnout> the rest of the BR developers: the naming issue.
Arnout> We have a tendency to make a copy of a package when there is a major
Arnout> version change, cfr. python3 and qt5. However, in this case, I don't
Arnout> think it's a good idea. At this time, many (most?) gstreamer
Arnout> downstreams have already moved to 1.x. Also, no more patches will be
Arnout> made the the 0.10 series (though distro's may still make patches). So
Arnout> we can expect the old gstreamer stuff to die out relatively
Arnout> quickly. But if we call the new thing gstreamer1 now, we're
Arnout> essentially stuck with that name for all eternity.
I'm not so sure. If you look at the other recent major version upgrades
(python/qt/gtk), it seems to me like people aren't jumping on the new
version right away. I had several people asking me if qt4 would still be
available once qt5 got added.
I think the nicest thing we can do for our users is just to add the new
package next to the existing when these incompatible major version
upgrades happen, so they can chose themselves when/if they want to
upgrade. I agree that gstreamer1 perhaps isn't the nicest name, but it
isn't too bad either, and for python/qt/gtk the names are commonly used.
Arnout> So instead I'd try to make 0.10 or 1.0 a choice in the gstreamer
Arnout> package itself. For me it's fine if inside the Config.in and the .mk
Arnout> files we basically have the two versions in a big ifeq() construct,
Arnout> but at least we can keep on using the BR2_PACKAGE_GST* symbols.
What would the advantage be? Just that people could move from gstreamer
0.10 to 1.0 without adjusting their config?
Arnout> Obviously, there will be some packages that break down when
Arnout> gstreamer 1.0 is used, but we'll have to discover that at some
Arnout> point anyway.
Like the closed source imx stuff.
Dear Peter Korsgaard, On Sat, 11 May 2013 23:31:12 +0200, Peter Korsgaard wrote: > Arnout> We have a tendency to make a copy of a package when there is a major > Arnout> version change, cfr. python3 and qt5. However, in this case, I don't > Arnout> think it's a good idea. At this time, many (most?) gstreamer > Arnout> downstreams have already moved to 1.x. Also, no more patches will be > Arnout> made the the 0.10 series (though distro's may still make patches). So > Arnout> we can expect the old gstreamer stuff to die out relatively > Arnout> quickly. But if we call the new thing gstreamer1 now, we're > Arnout> essentially stuck with that name for all eternity. > > I'm not so sure. If you look at the other recent major version upgrades > (python/qt/gtk), it seems to me like people aren't jumping on the new > version right away. I had several people asking me if qt4 would still be > available once qt5 got added. I agree. I recently had a customer using Buildroot, with a fairly important stack of custom/proprietary software written on top of gstreamer 0.10. Having the possibility to continue to use gstreamer 0.10 is very important to allow such users to migrate to newer Buildroot versions. The migration to gstreamer 1.x will not happen overnight for such users who have a large body of software written against gstreamer 0.10. Similarly for Qt4 vs. Qt5, as Peter mentioned. > I think the nicest thing we can do for our users is just to add the new > package next to the existing when these incompatible major version > upgrades happen, so they can chose themselves when/if they want to > upgrade. I agree that gstreamer1 perhaps isn't the nicest name, but it > isn't too bad either, and for python/qt/gtk the names are commonly used. Right. Ideally, we would have preferred to have 'gstreamer' be the latest available version, and 'gstreamer0.10' be the name for the old packages. But that doesn't work, because we can't predict the future. We had the same for Gtk. In the past we had package/libgtk and package/libgtk2, and now package/libgtk is gone. And presumably, we'll gain package/libgtk3 in the future. > Arnout> Obviously, there will be some packages that break down when > Arnout> gstreamer 1.0 is used, but we'll have to discover that at some > Arnout> point anyway. > > Like the closed source imx stuff. Hum, not sure to get your point here, though. Best regards, Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: Hi, Arnout> Obviously, there will be some packages that break down when Arnout> gstreamer 1.0 is used, but we'll have to discover that at some Arnout> point anyway. >> Like the closed source imx stuff. Thomas> Hum, not sure to get your point here, though. Well, it was late when I wrote this ;) I just meant packages like gst-fsl-plugins probably won't work with gstreamer 1.x
Dear Peter Korsgaard, On Sun, 12 May 2013 13:13:22 +0200, Peter Korsgaard wrote: > Arnout> Obviously, there will be some packages that break down when > Arnout> gstreamer 1.0 is used, but we'll have to discover that at some > Arnout> point anyway. > > >> Like the closed source imx stuff. > > Thomas> Hum, not sure to get your point here, though. > > Well, it was late when I wrote this ;) I just meant packages like > gst-fsl-plugins probably won't work with gstreamer 1.x Ah, yes, indeed. Makes sense now :) Thomas
On 12/05/13 11:23, Thomas Petazzoni wrote: > On Sat, 11 May 2013 23:31:12 +0200, Peter Korsgaard wrote: > >> > Arnout> We have a tendency to make a copy of a package when there is a major >> > Arnout> version change, cfr. python3 and qt5. However, in this case, I don't >> > Arnout> think it's a good idea. At this time, many (most?) gstreamer >> > Arnout> downstreams have already moved to 1.x. Also, no more patches will be >> > Arnout> made the the 0.10 series (though distro's may still make patches). So >> > Arnout> we can expect the old gstreamer stuff to die out relatively >> > Arnout> quickly. But if we call the new thing gstreamer1 now, we're >> > Arnout> essentially stuck with that name for all eternity. >> > >> >I'm not so sure. If you look at the other recent major version upgrades >> >(python/qt/gtk), it seems to me like people aren't jumping on the new >> >version right away. I had several people asking me if qt4 would still be >> >available once qt5 got added. > I agree. I recently had a customer using Buildroot, with a fairly > important stack of custom/proprietary software written on top of > gstreamer 0.10. Having the possibility to continue to use gstreamer > 0.10 is very important to allow such users to migrate to newer > Buildroot versions. The migration to gstreamer 1.x will not happen > overnight for such users who have a large body of software written > against gstreamer 0.10. > > Similarly for Qt4 vs. Qt5, as Peter mentioned. Fair enough. I guess Peter's right, having the 1 in the name doesn't hurt. Regards, Arnout
On Fri, May 10, 2013 at 6:38 PM, Arnout Vandecappelle <arnout@mind.be> wrote: > Hi Spenser, > > Very quick first review... > > First of all, a comment that is not so much directed at you but at the rest > of the BR developers: the naming issue. > > We have a tendency to make a copy of a package when there is a major > version change, cfr. python3 and qt5. However, in this case, I don't think > it's a good idea. At this time, many (most?) gstreamer downstreams have > already moved to 1.x. Also, no more patches will be made the the 0.10 series > (though distro's may still make patches). So we can expect the old gstreamer > stuff to die out relatively quickly. But if we call the new thing gstreamer1 > now, we're essentially stuck with that name for all eternity. > > So instead I'd try to make 0.10 or 1.0 a choice in the gstreamer package > itself. For me it's fine if inside the Config.in and the .mk files we > basically have the two versions in a big ifeq() construct, but at least we > can keep on using the BR2_PACKAGE_GST* symbols. > > Obviously, there will be some packages that break down when gstreamer 1.0 > is used, but we'll have to discover that at some point anyway. > Per discussion will leave as gstreamer1. > We nowadays prefer to put sub-options inside an if...endif construct > instead of with 'depends on'. Will fix. Please continue to review these patches and let me know of any additional issues. Regards, Spenser -- Spenser Gilliland Computer Engineer Doctoral Candidate
diff --git a/package/multimedia/Config.in b/package/multimedia/Config.in index 931e6d3..f6a5fd7 100644 --- a/package/multimedia/Config.in +++ b/package/multimedia/Config.in @@ -6,6 +6,7 @@ source "package/multimedia/faad2/Config.in" source "package/multimedia/flac/Config.in" source "package/multimedia/ffmpeg/Config.in" source "package/multimedia/gstreamer/Config.in" +source "package/multimedia/gstreamer1/Config.in" source "package/multimedia/gst-ffmpeg/Config.in" source "package/multimedia/gst-dsp/Config.in" source "package/multimedia/gst-fsl-plugins/Config.in" diff --git a/package/multimedia/gstreamer1/Config.in b/package/multimedia/gstreamer1/Config.in new file mode 100644 index 0000000..b1fd8b1 --- /dev/null +++ b/package/multimedia/gstreamer1/Config.in @@ -0,0 +1,37 @@ +config BR2_PACKAGE_GSTREAMER1 + bool "gstreamer1" + depends on BR2_USE_WCHAR # glib2 + depends on BR2_TOOLCHAIN_HAS_THREADS + select BR2_PACKAGE_LIBGLIB2 + help + GStreamer is an open source multimedia framework. + + http://gstreamer.freedesktop.org/ + +config BR2_PACKAGE_GSTREAMER1_GST_DEBUG + bool "enable gst-debug trace support" + default y + depends on BR2_PACKAGE_GSTREAMER1 + help + Enable support for the gst-debug tracing functionality in gstreamer. + This has limited CPU overhead, but does increase the rootfs size + somewhat. + +config BR2_PACKAGE_GSTREAMER1_PLUGIN_REGISTRY + bool "enable plugin registry" + default y + depends on BR2_PACKAGE_GSTREAMER1 + help + Enable support for the GStreamer plugin registry. This may increase + the launch-time for a GStreamer application. + +config BR2_PACKAGE_GSTREAMER1_INSTALL_TOOLS + bool "install gst-launch gst-inspect" + default y + depends on BR2_PACKAGE_GSTREAMER1 + help + Install the gst-launch and gst-inspect tools. This will take up + additional space on the target + +comment "gstreamer requires a toolchain with WCHAR and threads support" + depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS diff --git a/package/multimedia/gstreamer1/gstreamer1.mk b/package/multimedia/gstreamer1/gstreamer1.mk new file mode 100644 index 0000000..7abdc09 --- /dev/null +++ b/package/multimedia/gstreamer1/gstreamer1.mk @@ -0,0 +1,36 @@ +############################################################# +# +# gstreamer1 +# +############################################################# + +GSTREAMER1_VERSION = 1.0.7 +GSTREAMER1_SOURCE = gstreamer-$(GSTREAMER1_VERSION).tar.xz +GSTREAMER1_SITE = http://gstreamer.freedesktop.org/src/gstreamer +GSTREAMER1_INSTALL_STAGING = YES + +# Checking if unaligned memory access works correctly cannot be done when cross +# compiling. For the following architectures there is no information available +# in the configure script. +ifeq ($(BR2_avr32),y) +GSTREAMER1_CONF_ENV = as_cv_unaligned_access=no +endif +ifeq ($(BR2_aarch64),y) +GSTREAMER1_CONF_ENV = as_cv_unaligned_access=yes +endif + +GSTREAMER1_CONF_OPT = \ + --disable-examples \ + --disable-tests \ + --disable-failing-tests \ + --disable-debug \ + --disable-valgrind \ + --disable-benchmarks \ + --disable-check \ + $(if $(BR2_PACKAGE_GSTREAMER1_GST_DEBUG),,--disable-gst-debug) \ + $(if $(BR2_PACKAGE_GSTREAMER1_PLUGIN_REGISTRY),,--disable-registry) \ + $(if $(BR2_PACKAGE_GSTREAMER1_INSTALL_TOOLS),,--disable-tools) \ + +GSTREAMER1_DEPENDENCIES = libglib2 host-pkgconf host-bison host-flex + +$(eval $(autotools-package))
This patch adds the gstreamer version 1.x series to buildroot. Signed-off-by: Spenser Gilliland <spenser@gillilanding.com> --- package/multimedia/Config.in | 1 + package/multimedia/gstreamer1/Config.in | 37 +++++++++++++++++++++++++++ package/multimedia/gstreamer1/gstreamer1.mk | 36 ++++++++++++++++++++++++++ 3 files changed, 74 insertions(+) create mode 100644 package/multimedia/gstreamer1/Config.in create mode 100644 package/multimedia/gstreamer1/gstreamer1.mk