[gst-devel] a modest proposal
David I. Lehn
dlehn at vt.edu
Wed Oct 17 20:41:13 CEST 2001
* Andy Wingo <apwingo at eos.ncsu.edu> [20011017 18:58]:
> plugins need to be split off from the main cvs module. that's a known fact.
One man's fact is another man's opinion...
> There are a few goals of the arrangement, when it is done, imo:
> 1) there will be broad groupings of plugins that can be checked out.
> 2) they will all build from the same configure script.
> 3) they will not be in the gst source tree.
4) packaging (Debian, RH, etc) will not be made too difficult
> wrt 1, how about the following:
> * audio: audio-only stuff.
> * video: video, including a52dec. ac3dec must die.
> * 'system': http*. icecast? rtp*. gnomevfs.
Categorization is going to be impossible IMHO. See previous threads on
the topic for more complete and verbose proposals.
> wrt 2, it seems there will need to be an autogen.sh that will search the tree
> for files of a well-known name to make the configure.ac script. It has to be
> done this way because AC_OUTPUT has to output all .in's, not just for the
> plugins that can be built.
Have you seen OMS code? Please don't head down this path. You end up
with a system that is split up poorly and difficult to understand.
fwiw: oms had configure.incl in dirs that needed special configure
support. It >>ed them all together at top level. This is a mess
because you have dependencies issues in some cases which ends up as
multiple files checking for similar features. Admittedly in our case it
is probably a bit more clear cut for most plugins, but it's still a
mess. And a scan for all Makefile.am's sucks if you want to exclude
some of them or whatever. Blah.
> wrt 3, there is some stuff in GstHowTo about how to link to uninstalled gst.
> Also, we'd want to get gst configuration info as to where to install (is this
> right?). gstreamer-register has to be modified to somehow look in this different
> path for plugins. We need to figure out why libtool has problems linking to
> uninstalled gst when there is a copy of gst installed.
A GST_PLUGIN_PATH would be nice.
> Furthermore, any applications that are within gst's cvs repository need their
> own module with their own configure script (one for all: gstmediaplay,
> gsteditor, and perhaps even the test/ directory.)
> Should there be a docs module? I shudder to think.
> Anyway, comment on this and we can come to a conclusion. That would be very
Ok, here's my bold take on the subject and my reasoning:
We should not split up the plugins into their own modules.
Well.. perhaps an acceptable split is moving -all- plugins into a
separate gstreamer-plugins module and leaving gstreamer mod as core +
docs + tools.
Right now everything is nicely contained. Yeah, it's a big container
with warts. I think if we improved the current system we would be
a) flatten plugin dir.
one subdir per plugin. no subsubdirs. that just gets messy. much
easier to find plugin code this way. categorization will fail on
some level if we try.
b) move core plugins from gst/ subdirs to plugins/
uniform, consistent, obvious. leaves gst/ as just core libgst.
c) move major apps out to their own modules: gstmediaplay, gsteditor.
these are not part of the GStreamer framework but are users of it.
d) keep all docs in main modules: API, manual, pwg.
API should certainly stay in main module. manual and pwg are
arguably tied to the current code base, IMHO seems appropriate to
leave them together.
e) rewrite/fix docs build.
way too hard to get working or fix now. probably a serious
challenge to improve though.
f) improve build system.
1) migrate to more uniform automake usage where possible.
2) take advantage of am 1.5 creatures like target specific _CFLAGS.
3) top level optimization/arch flags (in concert with #2 i think)
4) write some m4 macros to make configure.ac easier to maintain.
5) drop support for old autoconf/automake. it's not unreasonable to
require developers to have latest tools
6) perhaps adopt a simple linux kernel like config util to select
features and plugins you want. this would just output a script
with appropriate flags for configure. #4 would provide a fairly
uniform way to enable/disable and scan for available plugins.
Advantages of this approach:
* everything together in one tarball
* easy to build everything
* with f.6 easy to build partial tree
* global changes (ie, to gst/ headers) easy to propagate
* not exchanging contained-somewhat-sane global build we have now for
scripts to do the same thing (ie, auto gen of configure.ac, etc)
* (perhaps) most people will want to install as many plugins as they can
anyway. many modules is headache in this case.
* distribution packaging (ie, debs) easier with 1 module
* it works now, don't break it.
* improvements to single plugins require new release of everything.
counter argument: in practice i don't see this as a problem. i
foresee plugins stabalizing and the real work will be in the
applications. frequent releases isn't such a bad idea either.
and of course anyone can get the updates from cvs.
* dependencies per module: many-for-1 vs ~1-for-each-of-many
* Composite elements: plugins with elements depending on other elements.
would be nice if build system were smart enough to deal with such
things. could be part of f.6 as well. may be more difficult with
many modules. (?)
David I. Lehn <dlehn at vt.edu> | http://www.lehn.org/~dlehn/
Computer Engineering Graduate @ Virginia Tech in sunny Blacksburg, VA
More information about the gstreamer-devel