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

Reimar Döffinger Reimar.Doeffinger at gmx.de
Wed Dec 31 16:25:03 CET 2014


On Wed, Dec 31, 2014 at 03:43:32PM +0100, Clément Bœsch wrote:
> On Wed, Dec 31, 2014 at 02:57:43PM +0100, Reimar Döffinger wrote:
> > 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.
> > 
> 
> How is that really a problem? You can just ./configure
> --prefix=$PWD/install (or wherever you fancy) from the library source
> directory

If you do that you end up with an unmaintainable mess where you have all
the files from all programs you ever installed in that directory.

> You're supposed to have your .pc file in $PREFIX/lib/pkgconfig/x264.pc
> along with $PREFIX/lib/x264.pc
> 
> You obviously need to make pkg-config point on the appropriate directory
> if it's in a special place (with PKG_CONFIG_PATH). And this process is
> widely documented.

Where? How would a user who just went to x264.org because he was told to
try a newer version ever come across this information?
Sure, if you search for explicitly you'll find it, but why would a
semi-ordinary user?
Also I'm not arguing it's impossible, I'm arguing it's inconvenient.
It's something like 2-3 additional steps for each library.
I find it very reasonable to try to support special use-cases, I hate
all those projects that end up working only on the developers' machines
because every other configuration is "unreasonable".
pkg-config is always going to be harder to debug when things go wrong
because you can end up with all kinds of random compilation flags (for
example an "innocent" -L/usr/local/lib that ends up breaking other
libraries, but configure can't detect that because it's added only after
all the tests were done).
I do very much like the idea that you can do e.g.
--pkg-config=/bin/false that makes a configuration that works on "most"
systems and the parts that don't work can be fixed just by
--extra-cflags or --extra-ldflags.
No hacking with broken .pc files or having to do other tricks or having
to specify -l... for every single library (like for the
--pkg-config=/bin/true solution).
I am very open to look for solutions of specific issues like the complexity of that
as done now or it being enabled by default but I find the "if you're not
using pkg-config you are doing it wrong and we should not even try to
make things easier for you" argument not something I really agree with,
even if it's in many cases correct on the "doing it wrong" part.


More information about the ffmpeg-devel mailing list