[FFmpeg-devel] [PATCH]Allow libspeex detection also without pkg-config

[Reimar Döffinger]

On Wed, Dec 31, 2014 at 02:38:20PM +0100, Clément Bœsch wrote:
> On Wed, Dec 31, 2014 at 02:23:54PM +0100, Reimar Döffinger wrote:
> > On Wed, Dec 31, 2014 at 02:09:42PM +0100, Nicolas George wrote:
> > > Le primidi 11 nivôse, an CCXXIII, Reimar Döffinger a écrit :
> > > > I don't care much, but I still find not having to use pkg-config
> > > > somewhat more convenient in a cross-compilation environment where
> > > > you don't want to install all dependencies just to make it work with
> > > > pkg-config (or alternatively manually hack those files).
> > > 
> > > Can you elaborate on that? I suspect there are ways of making this work
> > > easily with pkg-config, but you are to vague about the dependencies you want
> > > to avoid, so I can not suggest a way.
> > 
> > If I just download libspeex, libfdk_aac, libsdl etc. and build them
> > with CC=i686-mingw32-gcc ./configure, then without pkg-config I can
> > just add a few paths to -I and -L and I can link against them.
> > With pkg-config things tend to get inconsistent and more complicated.
> > For example some programs (no, I haven't tried lately so I don't
> > remember examples) generate them only on install, so you have to
> > make install. But to do that you have to figure out how to specify
> > a install directory.
> 
> The .pc files are obviously generally generated because the library they
> depend on (for static stuff) depends on your configure options, so
> obviously that's what you want: flags automatically added that way.

The problem isn't them being generated.
The problem is if it is only "make install" that generates them.

> > Even if they don't, you still have to add the .pc paths in addition.
> > From my point of view it's only more convenient if all you want to
> > use are things that are pre-packaged by your distribution.
> > Btw. would you be less opposed to a patch that added less obfuscation?
> 
> > It looks to me like we would just require an extra "fallback -l" option
> > (preferably also a fallback extra cflags one) to use_pkg_config to allow
> > hiding all the extra complexity in one place, inside that function.
> 
> The problem is that the fallback is really broken. pkg-config has a
> mechanism to check for version, it also has a mechanism to raise different
> flags depending on the build, and it also has a system to differenciate
> the flags necessary for static or dynamic building.
> 
> Look at the current multiline and unreliable (no pkg-config + x264 with
> opencl will badly break)

That is not obvious to me, why would it badly break?
If it does, doesn't that mean require_pkg_config will break the same
way if your .pc happens to be from a non-opencl x264 by mistake,
and thus it would be better to fix anyway?

> And if the user doesn't have pkg-config, an explicit error is raise: "you
> must install pkg-config", which is simpler to solve than a weird linkage
> error on opencl in the config.log and an error saying "i can't find x264"

It's not necessarily easier to solve when users end up with broken .pc files.
Which happens easily if they e.g. have a system x264.pc file and try to
use a locally compiled one (with OpenCL enabled for example).
If we don't have a reliable detection, these issues will happen even
with pkg-config.
And if we have a reliable detection, except for the complexity we need
to handle I don't see a big issue with making a least-effort attempt
without pkg-config.