GNOME Bugzilla – Bug 773288
Upstream gst-all
Last modified: 2016-10-26 22:39:58 UTC
<thiblahute> __tim: How do you feel about upstreaming gst-all now? We even got someone build it on windows https://github.com/thiblahute/gst-all/pull/2 :) We should do this, basically as a meson version of gst-uninstalled. Niggles/open questions: - name: I'd prefer something like gst-build or gst-devbuild or such - folder hierarchy: gst modules shouldn't be in subprojects/* (meson requires this of us currently, ideally we can improve meson to allow them elsewhere too; short-term we could add symlinks on systems that allow it) - needs options to specify which modules to build and/or not build - should it build everything by default? If not, what should it build or not build? (gst-rtsp-server? ges? gst-devtools? gst-examples?)
- I don't like the meson submodule, we should remove it and specify the req appropriately
- also don't like the ./configure script, how about we call it ./setup or such instead ;)
At least gst-python should not be built by default IMHO, as: Executing subproject gst-python. ... Native dependency pygobject-3.0 >= 3.0 found: YES 3.22.0 Dependency python3 found: NO Meson encountered an error in file subprojects/gst-python/meson.build, line 22, column 0: Dependency "python3" not found
(In reply to Tim-Philipp Müller from comment #1) > - I don't like the meson submodule, we should remove it and specify the req > appropriately Removed now that we have a working release (0.35) we need to make sure following releases will work, our jenkins build should help with that. (In reply to Tim-Philipp Müller from comment #2) > - also don't like the ./configure script, how about we call it ./setup or > such instead ;) Really? Do you actually care? :) (In reply to Tim-Philipp Müller from comment #3) > At least gst-python should not be built by default IMHO, as: > > Executing subproject gst-python. > ... > Native dependency pygobject-3.0 >= 3.0 found: YES 3.22.0 > Dependency python3 found: NO > > Meson encountered an error in file subprojects/gst-python/meson.build, line > 22, column 0: > Dependency "python3" not found Well, you do not have python3 headers, does not sound like a massive argument to me :) ... DONE though We should make it possible to have required: false in subproject() in meson. > - folder hierarchy: gst modules shouldn't be in subprojects/* (meson requires this of us currently, ideally we can improve meson to allow them elsewhere too; short-term we could add symlinks on systems that allow it) symlinks to the root dir?
> > - folder hierarchy: gst modules shouldn't be in subprojects/* (meson requires this of us currently, ideally we can improve meson to allow them elsewhere too; short-term we could add symlinks on systems that allow it) > > symlinks to the root dir? OK I am now trying to symlink built subprojects to the rootdir: https://github.com/thiblahute/gst-all/commit/76c062b522155a8b403536b3e413a6449ae06ac2
> > - also don't like the ./configure script, how about we call it ./setup or > > such instead ;) > > Really? Do you actually care? :) I do, because it will be confusing for people if it's called ./configure imho, being the name used by autotools etc. I also don't want to set a precedent for that build API thing ;) > (In reply to Tim-Philipp Müller from comment #3) > > At least gst-python should not be built by default IMHO, as: > > .. > > Dependency python3 found: NO > > Well, you do not have python3 headers, does not sound like a massive > argument to me :) ... DONE though Thanks. It is a bit of an argument because it would have meant we'd make python3-dev a hard dep on our new gstreamer build which I think is unnecessary given that gst-python is simply a fringe module and doesn't warrant that.
> > Well, you do not have python3 headers, does not sound like a massive > > argument to me :) ... DONE though > > Thanks. It is a bit of an argument because it would have meant we'd make > python3-dev a hard dep on our new gstreamer build which I think is > unnecessary given that gst-python is simply a fringe module and doesn't > warrant that. My counter argument is that we are already building gi stuff and it means that people will be able to use Gst from python in the env but with big issues due to the fact gst-python has not been built.
(In reply to Tim-Philipp Müller from comment #0) > Niggles/open questions: > > - name: I'd prefer something like gst-build or gst-devbuild or such TODO while moving to FDO > - folder hierarchy: gst modules shouldn't be in subprojects/* (meson > requires this of us currently, ideally we can improve meson to allow them > elsewhere too; short-term we could add symlinks on systems that allow it) DONE: https://github.com/thiblahute/gst-all/commit/85880a3a22e3effccdb6e573543926b18eeae519 > - needs options to specify which modules to build and/or not build DONE: https://github.com/thiblahute/gst-all/commit/3875f0c705290fca31a1e83586a25a17645c6713 > - should it build everything by default? If not, what should it build or > not build? (gst-rtsp-server? ges? gst-devtools? gst-examples?) DONE: We now have gst-python that is disabled by default (not 100% convinced it is a smart move, but well :)) and we have options to disable the others. (In reply to Tim-Philipp Müller from comment #1) > - I don't like the meson submodule, we should remove it and specify the req > appropriately DONE: https://github.com/thiblahute/gst-all/commit/b0bcc4002631ac6364b0f1054fe6700f90f89cb4 (In reply to Tim-Philipp Müller from comment #2) > - also don't like the ./configure script, how about we call it ./setup or > such instead ;) DONE: https://github.com/thiblahute/gst-all/commit/526a5cd04ac37039ec21c0b5d4253722eacf915e Anything else? Or should we move forward? :)
Now all that's left is the bikeshed about the name. ;) I propose 'gst-builder'. ~*starts singing the Bob the Builder theme song*~
Was still brainstorming names, haven't seen anything I like better than gst-build so far though - gst-build was our favourite so far, right?
+1 for `gst-builder`
https://cgit.freedesktop.org/gstreamer/gst-build/