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

Reimar Döffinger Reimar.Doeffinger at gmx.de
Wed Dec 31 19:01:33 CET 2014


On 31.12.2014, at 16:52, Nicolas George <george at nsup.org> wrote:
> Le primidi 11 nivôse, an CCXXIII, Reimar Döffinger a écrit :
>> 
>> 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.
> 
> How do you usually install a library? You are very vague about your use
> case and usual methods.
> 
> In particular, you did not explain what case you want to make simpler:
> installing a library properly? using the library from the temporary build
> directory to just test something? something else? Any of these cases can be
> optimized, but not all the same way.

There is no "the case". I want to be able to easily hack and fix things when things go wrong or I happen to be in front of an unusual system.
But it will be about quick hacks, so using one or several libraries from where I compiled them (as then you can test changes by just running "make" in each).

> Anyway, in my administration experience, installing a library properly
> requires a good dozen steps beyond make install to get things working
> properly without breaking the system; the exact steps depend on what
> administration tools are used: create a package, install with symlinks, etc.

Just to make this completely clear: I never, ever, ever want to install anything that is not in a distribution repository.
Exactly because it requires all those steps and you _never_ get it right.

> Anything you want can be made to work easily with a configure that only uses
> pkg-config, you just have to explain accurately enough what you want.

I don't really care much about improving _one_ use-case, I'd ideally want all imagineable use-cases to "just work with a bit of hacking" - with empasis on minimal effort and number of steps, and steps that I can remember without documentation - cleanliness is not a concern at all (aka "hackability").
Especially those use-cases I do not yet know about.
And pkg-config is a concern to me as I don't think I'll be able to fix issues with it quickly and easily when it fails.

But just to have more than just hand-waving: a major specific use-case is compiling for MinGW using cygwin.
To be more accurate I just tried it myself again, and most issues are not even related to pkg-config.
It starts with --cross-prefix requiring to specify target os and arch (no, I really don't. I can just comment out this annoying error). Btw. configure just assumes HOSTCC==gcc to work without even checking that gcc is in the PATH...
X264 configure is too stupid to figure out that using x86_64-w64-mingw32- very much doesn't mean it should use -m32...
But after that I just need to add --extra-cflags=-I$HOME/x264 --extra-ldflags="-L$HOME/x264 -pthread"
And it actually works even though x264 was configured with OpenCL (unintentionally actually).
If I want to use pkg-config, I'd have to either install libx264 (also remembering to set the prefix, otherwise you might end up overriding your installed version in /usr/local, plus you have to re-run the whole build process) or set PKG_CONFIG_PATH _and_ edit the .pc file so it doesn't use whatever binaries exist in /usr/local instead (as this will not only affect x264 but all libraries).
That might sound minor, but I consider that more than worth a few extra lines of configure code.

Interestingly, the --pkg-config=/bin/true workaround needs you to be careful to actually put libraries in --extra-libs, not --extra-ldflags or the check will fail for static libraries, which is not completely obvious/100% matching how other configure implementations do it.
> 

It is an alternative, but one you have to know about/think of and still is a bit of extra work.


More information about the ffmpeg-devel mailing list