[gst-devel] Can't make gstreamer work

[David Given]

[...]
> The debian Makefile doesn't do anything special with auto* stuff.  And
> I'm not sure how useful that stuff is without the .diff.gz with a few
> other fixups in it.  If you're getting missing AC/AM stuff you make want
> to 'export ACLOCAL_FLAGS=-L /usr/local/share/aclocal' before running
> autogen.sh.

[~/src/gstreamer-0.2.1]
dg at pearl [507] [17:25:48] export ACLOCAL_FLAGS=-L 

[~/src/gstreamer-0.2.1]
dg at pearl [508] [17:27:56] aclocal
aclocal: both `configure.ac' and `configure.in' present: ignoring `configure.in'

[~/src/gstreamer-0.2.1]
dg at pearl [511] [17:28:33] chmod a+rx makeconfigure 

[~/src/gstreamer-0.2.1]
dg at pearl [512] [17:28:37] ./autogen.sh 
Checking for patched automake... found.
I am going to run ./configure with no arguments - if you wish 
to pass any to it, please specify them on the ./autogen.sh command line.
You should update your `aclocal.m4' by running aclocal.
aclocal: unrecognized option -- `-L'
Try `aclocal --help' for more information.
aclocal failed - check that all needed development files are present on system

(makeconfigure wasn't executable, BTW.)

Is it worth getting the latest CVS and trying again?

[...]
> Perhaps autoplugger failing?  Do the test/ tests/ examples work?
> Hardcoded pipelines are less likely to have errors like that.

I have to confess I hadn't even found the examples! I shall try them and
report back.

> > (BTW, the prebuild Debian gstreamer packages are built against X 4.1. As 4.1
> > is still in unstable, they're not a lot of use to people.)
> > 
> 
> Well... latest 4.1.0-5 is high priority so maybe that will get into
> testing quicker.  But what would you suggest?  Many of the plugins are
> written to the latest and greatest APIs which are only in unstable
> anyway.  (correct me if I'm wrong about that)   The reason they are they
> way they are is that it's easiest for me to build them like this.  I
> haven't made a chroot environment with stable packages installed just to
> build debs yet.  And based on all the problems you're having would you
> really suggest this code is ready for stable? ;-)

Hmm. Okay. (I was just checking that there was a reason and it wasn't an
oversight. At this stage it's probably better to recompile it and not trust the
prebuilt binaries, anyway.)

> > (Also BTW, is anyone working on Python bindings?)
> 
> I've wanted to do them for, oh, 8 months now ;)  Some guy who did bonobo
> bindings poped into IRC a week ago and sounded like he was doing
> something about it.  No code yet though.  I really want to get it so we
> can subclass the gtk objects and all that jazz.  Feel free to take a
> stab at it if you want.  I suggest trying the glib/gtk2 binding code to
> try and do most of it automatically.

I'd be happy too; as you say, the gtk binding code should make it easy. I'll
get the stuff and have a look.

-- 
+- David Given --------McQ-+ "Under communism, man exploits man. Under
|  Work: dg at tao-group.com  | capitalism, it's just the opposite." --- John
|  Play: dg at cowlark.com    | Kenneth Galbrith                                   
+- http://www.cowlark.com -+