[gst-devel] install problems
richard at tartarus.org
Tue May 22 15:51:40 CEST 2001
> It probably should have been there and I have no idea why it wasn't.
You are probably missing an esound-dev package on your production machine.
> My question : is it gstreamer's responsibility to check for this or not ?
> Is it something that needs to be looked in before a next release ?
The problem is really that the idea of aclocal is a nasty hack (and indeed
aclocal is being removed / reworked for the next major release of
automake, I believe).
A possible solution would be to check-in a working aclocal.m4 to the CVS
tree: I'm reluctant to advocate this though since its a generated file and
will frequently be modified in peoples own trees, making checking in of
changes, etc, inconvenient.
An improvement would be for autogen.sh to fail if aclocal fails. This
would at least point out the error if it occurred.
Another possibility would be to generate frequent snapshots of the code
with the configure and Makefile.in's included (ie, the result of "make
dist"), and advocate their use to those wishing to play around with the
Another solution would be to put all needed macros into acinclude.m4, but
this has the drawback that these versions of macros will be used in
preference to more up-to-date macros installed on the system, which may
Finally, we could just wait for automake to fix this problem: I think that
what is going to happen is that automake will have a directory into which
any desired macros can be placed, but these macros will be overridden by
those present on the system. Currently, the system will fail if a macro is
present twice in aclocal's include paths, so I can't see a way to hack this
behaviour into the current system.
I think that autogen.sh should fail if aclocal fails regardless of other
fixes, so I've just committed a fix that makes that happen.
More information about the gstreamer-devel