[gst-devel] plugins

[David I. Lehn]

* Thomas Vander Stichele <thomas at urgent.rug.ac.be> [20011210 13:19]:
> 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.
> 

Yeah, that's ok I guess.  Keep in mind that embedded targets may want to
statically link everything at some point.  Omega, I guess you've looked
at this more than any of us.  Will sepearte plugins be ok in that
respect?


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

Quite frankly, if these phantom people can't figure out how to just
build audio plugins with our phantom new CML build system, fuck em.
This stuff is complex, splitting things up makes it harder to maintain,
IMHO.  Now if you want to make extra tarballs vs standard ones, fine,
but I think it's a waste of time.  I'm really going to freak out if I
have to maintain debian control stuff across N packages.


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

My lunch money today would pay for space for 8 builds. ;)  A better
build system would cut that down since you could just build pieces you
need.


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

You have maintainer mode on right?  Makefile.am changes take like <30
seconds to process.  configure.ac changes take longer though.  I don't
see how spliting things up makes build time shorter.  A change to the
core will require build and install of core plus rebuild and install of
everything else.  How does this take less time?


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

Well, keep in mind that N packages means N build systems.  Make sure
that doesn't take N times as much time to maintain.  You've done great
job cleaning this stuff up.  Feel free to stick around and do this more
often for releases. <evil grin>


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

Um. Speaking as a developer I think the way it is now plus a CML like
build system would be fine.  Splitting things up beyond
core+plugins+apps... (check my old mail for split I proposed) is just
going to suck for packaging.  It's kinda nice right now with the whole
thing just requireing one build command and all the debs pop out.  But
major splitup is ok....

I'm repeating myself.  Read my old mail.


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

How does this suck?  On first glance I thought it was exactly what
everyone wanted?  Just click "All plugins" button for a full build.


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

Once again, I talked about this in my prior mails on the subject.
Plugins categorization is better done at some other level than dir
hierarchy since perfectly valid reasons will exist to put plugins in two
places.  See for instance your arguement about audio+video plugin
placement.  And speaking from experiance I find it much easier to just
see a big flat list of plugin dirs vs trying to search down through a
tree to find something i can't remember the name of.  Yeah yeah, I know
about ls -R, tree, find, etc ;)

-dave
-- 
David I. Lehn <dlehn at vt.edu>  | http://www.lehn.org/~dlehn/
Computer Engineering Graduate @ Virginia Tech in sunny Blacksburg, VA