[gst-devel] Plugin split proposal comments

[Erik Walthinsen]

OK, I'm gonna try to respond to the split-proposal mail in a reasonably
coherent manner...  pfff, who am I kidding? <g>


wingo> Should there be a docs module? I shudder to think.
taaz> d) keep all docs in main modules: API, manual, pwg.
taaz>    API should certainly stay in main module.  manual and pwg are
taaz>    arguably tied to the current code base, IMHO seems appropriate to
taaz>    leave them together.
Right, the docs are actually *derived* from the main lib source code, so...


taaz> fwiw: oms had configure.incl in dirs that needed special configure
taaz> support.  It >>ed them all together at top level.  This is a mess
We won't be doing this, because as you say, it's broken.  AFAIK, OMS has
some nasty interdependencies because of its structure.  The plugins, on
the other hand, have no interdependencies.  They only depend on libgst and
external libraries.  I'm downloading gtk+-all right now to see how that's
done, but it won't involve includes or any of that nastiness.  Each
package will be totally usable on its own, the global build will just
co-opt the build processes internally somewhat.  More when I read through
gtk+-all.

taaz> Just cating together configure.ac fragments is hard if you want them
taaz> to also be independent.  Like if two plugins require a header foo.h,
taaz> you have to put the check in both places.
First of all, autoconf has the ability (as used by gtk+-all, now that I've
read through it) to have a toplevel configure script call the others in a
row.  A very useful feature here is that it unifies the config.cache
handling, so checks performed the second, third, etc., time around are not
actually performed.  Any check performed in one directory is cached for
the next.

Now, there's a problem here: pkg-config sucks atm.  It needs to be totally
reworked in the autoconf context.  This is probably gonna be one of my
projects in the near-term.  It has little respect right now for the
autoconf way of doing things, and it throws caching out the window.

steveb> CML2 should handle the level of configurability we require.
Seems like this would make the most sense for this gst-all package.  You
configure what plugins you want at the top level, and it deals with the
'nasties' of configuring and building only what you specify.  No support
is needed in the individual packages themselves.


taaz> Categorization is going to be impossible IMHO.  See previous threads
taaz> on the topic for more complete and verbose proposals.
It all depends on what our objective is for categorization.  I know we
can't come up with a categorization that has perfect locations for every
plugin, simply because there is so much overlap.  But we need to try.
I'll try to come up with a categorization and a rationale next.  Others
should try the same.  The idea would be to discuss the various axes of
differences, and see if we can come up with a set that's reasonably
orthogonal.


taaz> We don't even split those up now!  vorbisenc/dec are combined into
taaz> one plugin lib: libgstvorbis.
Yeah, we have too many instances where we've got plugin explosion.  The
whole idea of a plugin being able to register a whole set of plugins is to
do first-level categorization.  We need a gstvorbis plugin with both
vorbisenc and vorbisdec elementfactories, as well as the vorbis
type/typefind, etc.  Put it in the vorbis/ directory somewhere (whether
it's a cvs module/package or just a subdir).


taaz> This was assuming core+plugins in same package I guess.  It's not
taaz> like the gst/elements/ elements have much value alone either.
taaz> Except of course for a dd(1) replacement. <g>
Yeah, gstelements needs to stay with libgst, because it's the basis for
all the pipelines.  However, httpsrc is one element that should be either
moved out of gstelements, or replaced with one that has no external
dependencies (ick, writing all the http code again...).


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


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

taaz> We have no way to pass global optimizations to subdirs.  Would be
taaz> nice to set -march=atari800 at the top level.  This does require all
taaz> subdirs to actually pay attention and add $(GST_ARCH_CFLAGS) to
taaz> AM_CFLAGS.  In any case, I'm lobbying for the GST_ARCH_CFLAGS to
taaz> exist.
Yes, we need to seriously rethink the way we handle CFLAGS.  The current
mess is partially caused by the fact that everything is in a single
package.  We have to special case the core libgst CFLAGS, and then deal
with the plugin CFLAGS.  We should definitely make use of the newer am1.5
features.


taaz> c) move major apps out to their own modules: gstmediaplay,
taaz>    gsteditor. these are not part of the GStreamer framework but are
taaz>    users of it.
Yes, these definitely need to be moved to separate modules.  Big question
is: libgstplay won't have any dependencies other than gstreamer, but
gstplay will.  Do we keep them in the same module, or separate them?
The editor doesn't have that problem because libgsteditor depends
fundamentally on gnome stuff, just like the app (which is about 5 lines of
code, actually).

      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_