[gst-devel] plugins

[Thomas Vander Stichele]

Hi taaz,

I'll take your points on one by one, because you've made me think some
more about it.

> The more I think about it I really don't see the need to split up
> anything.  It makes it a whole lot WORSE for me.  I'm going to install
> the whole thing anyway, having to deal with N source tarballs and
> build/install them in order is just annoying.

Well, 
a) using two tarballs should be possible.  one for gstreamer-core and
one for gstreamer-plugins.  That is totally manageable. Compare to xine
for example.

b) my idea, from the start, was to make smaller tarballs as well, for
example only containing audio stuff.  There's no reason we can't have one
large tarball and a few smaller ones that add up to the same tarball.  So
I consider this a good solution to your complaint.  Let me know if you
agree ;)

The reason I'd allow for smaller tarballs is just the reason I gave in my
mail.
Suppose we get some people from another audio project to write some
plugins.  We're far too demanding in the learning curve area right now to
make it easy on them.
While, with my idea, we could just tell them to install the core
RPM's/debs, except for the area they'll be working on (for example,
audio-int, because they'll write us a nice resampler).  We tell them to
get that audio-int source tarball and work on that.  He can be sure the
RPM's are quality stuff and not too blame (hopefully) and concentrate on
getting this one plugin to work.
Anything we can do to make the threshold for new users lower is good in my
book.

> So what problem are you trying to solve?  Source tree too big?  Disk
> space is cheap so that's probably not true.  

Well I like to work on my laptop with gstreamer and try out a few builds.
One build with not even everything turned on takes 230 MB.  That's
ridiculous. So yeah, space is an issue.  But even more ...

> I bet I know what it is...
> you don't want to wait for the build system to go through and build
> plugins you'll never use.  Just because you had the dev libs installed
> doesn't always mean you care about those plugins.  Right?

Right.  I've been fixing build issues all weekend, and I've had dev libs
installed for more than half the plugins because I'm doing Quality Control
this weekend.  We want to get a release out, and we might have managed to
have done that yesterday IF THE SOURCE TREE WASN'T SUCH A HUGE BEAST !!! I
mean, come on, I have three +800Mhz machines, and each time I tried fixing
something, I had to wait HALF AN HOUR for the result !
So maybe I could be smarter about the whole autotools stuff, but until I
am, and as long as I'm fixing these things, we might as well make it easy
to debug, no ?

Bottom line, is, that I've had about enough this weekend of the current
source tree and I'm not going to spend any more of my free time fixing
build issues ever again as long as everything is just one big lump.
I don't think I'm the only one to feel that way about it after they've
spent a whole weekend on it.  We need to release more often and we need to
quality-test more often if we have any hope of ever getting into gnome, if
that is considered a goal for us.

> So why not fix the build system?  CML and perhaps other newer kbuild
> stuff looks interesting.  Linux kernel solves the exact same issue.
> Users don't want to build support for everything so they have a config
> system.  

Some people are working on CML.  There's no reason a sensible source tree
split-up should make it harder for the users.  It does, however, make it
a lot easier for us, gstreamer developers, to work on a decent build
system, and provide decent quality assurance, and do automatic test
building, and so on.  For an automatic test build to be of any use, you
need to turn on *everything*.  I'd rather the tests would take on
manageable chunks than the whole gstreamer package.

> They don't split things up because it would make things worse
> due to dependency tracking and interface changes updating and so on.  We
> could have a config file or something that lists which plugins you want
> or don't want or whatever.  Perhaps some wildcard like system with
> keywords if we get fancy.  Then tell the auto* tools to only build the
> plugins you asked for.  Complain loudly if user selected a plugin
> without having the needed prereqs.

Totally agree with you on this. 

> Wouldn't this work for everyone?  Takes a few mins to pick plugins you
> like, then build is just what we have now except it just does the
> plugins you want.

As I've said : great for users, sucks for us developers who want to get a
release out and assure that they're delivering a package that builds.

> I do think we could rearrange some of the plugin dir.  It's not very
> consistent in a few places.  Like I've said eariler, I'd just as soon
> see it become a flatter hierarchy.

Well, that's just a matter of taste.  What I want to know, apart from the
fact that you like a flatter hierarchy more, is if you have any reasons
against my proposal ? I mean, does it make more sense and would you be
willing to work with it ?

Thanks,
Thomas

The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
<-*-                      -*->
god loves his children
yeah
<-*- thomas at apestaart.org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/