[gst-devel] a modest proposal

[Andy Wingo]

Hi David,

On Wed, 17 Oct 2001, David I. Lehn wrote:

> One man's fact is another man's opinion...

granted.

> > 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

good call.

> 
> 
> > 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.

I searched google, but it didn't come up with anything. Geocrawler search is
broken afaik.

what is wrong with that categorization per se, autotools issues aside?

> > 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.

what plugin depends on what other plugin? I don't get it. and if it is the case
that no plugin depends on any other (where 'plugin' == .so, not the individual
sinks/sources), why would this be difficult?

> > 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.

indeed. but I hate having to have env. vars set for progs to work. what about
gst-register keeping track of which dirs are registered and not in its confdir?
perhaps in addition to your sol'n.

> Ok, here's my bold take on the subject and my reasoning:

ready :-)

> 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.

if we don't split them in a modular fashion, what's the point?

> 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
> better off:
> 
> 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.

at least allow subdirs that are relevant, ie vorbis/vorbis[enc/dec]/. finding
the code is a good point. how does this categorization fail, again?

> b) move core plugins from gst/ subdirs to plugins/
>    uniform, consistent, obvious.  leaves gst/ as just core libgst.

then you can't even *test* gst without the plugins installed

> c) move major apps out to their own modules: gstmediaplay, gsteditor.
>    these are not part of the GStreamer framework but are users of it.

agreed.

> 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.

ok.

> e) rewrite/fix docs build.
>    way too hard to get working or fix now.  probably a serious
>    challenge to improve though.

ok.

> f) improve build system.
>    1) migrate to more uniform automake usage where possible.

good call

>    2) take advantage of am 1.5 creatures like target specific _CFLAGS.

what's this about?

>    3) top level optimization/arch flags (in concert with #2 i think)

i don't understand what you're going for here

>    4) write some m4 macros to make configure.ac easier to maintain.

good call

>    5) drop support for old autoconf/automake.  it's not unreasonable to
>       require developers to have latest tools

amen, brother!

>    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.

this is intriguing, and could solve my concerns about categorization. I just
don't want to have to go through hoops to disable all video plugins, and this
could do it for us. Still, another program to maintain, but hey. Sounds pretty
cool to me. This might even solve the splitting-modules-out problem. I really
don't want to have to recompile all plugins when something really minor in core
changes though.

> Advantages of this approach:
> * everything together in one tarball

this is good

> * easy to build everything

this is good too :)

> * with f.6 easy to build partial tree

yes

> * global changes (ie, to gst/ headers) easy to propagate

yup

> * not exchanging contained-somewhat-sane global build we have now for
>   scripts to do the same thing (ie, auto gen of configure.ac, etc)

of dubious value, we'd have to make f.6 anyway

> * (perhaps) most people will want to install as many plugins as they can
>   anyway.  many modules is headache in this case.

see next

> * distribution packaging (ie, debs) easier with 1 module

this should perhaps be a possibility, but not a necessity, for reasons below

> * it works now, don't break it.

what if it sucks?

> Disadvantages:
> * 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.

this is good iff plugins are in their own module

> 
> Half-n-half:
> * dependencies per module: many-for-1 vs ~1-for-each-of-many

this sucks sucks sucks! for binary packages anyway. the point of binary
packaging is to make things easy. with debian it's not so bad but if the user
has to hunt from here to yon to get their rpms to work, this is a pain. this is
much worse than halfway imho.

> Issues:
> * 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. (?)

do these exist?

thanks for the insightful email.

cheers,

wingo