On Thu, Aug 21, 2014 at 11:23:41AM +0000, Carl Eugen Hoyos wrote: > Clément Bœsch <u <at> pkh.me> writes: > > > > I thought the purpose is to allow educated developers > > > to use pkg-config while (uneducated) users (like me) > > > will not understand how this is easier than using > > > configure parameters. > > > > Yes, it's also simpler for the users. > > Please understand that we disagree on this point. > (It makes no difference though, I already accepted > that some developers need pkg-config for x264, opus > and hevc.) > > > > > They will also almost never be tested, > > > > > > I will care about the testing. > > > > Well, you probably won't test static linking of random > > libs on various platforms typically. > > If you don't allow testing this on your fate > client, I will have to take care. >
It's a generic linux, it would only cover a very limited usecase. If you want to test this properly you'd have to: - create multiple builds of the target library with different compilation flags (for x264 that would mean with or without opencl for example) - follow that project to look for any potential new library dependency addition - test with static and shared - test with minimal other dependencies in the build (because other places could add a linker flag or something that happen to actually be a dep you forgot) ; this mean an instance per library check - test on different plateform, where the linkers behave differently Are you willing to do that or... > > pkg-config makes possible to completely ignore that > > part since it moves the responsibility away from us. > > Completely apart from the fact that we already know > this doesn't work, I still consider it an undesired > change of behaviour. > ...simply trust the project delivering the .pc? > > That said, if you want to support a fallback as I > > suggested above, it won't work as you expect: > > I feel that all this only supports my point that we > should not rely on pkg-config. No, it shows that the hack is not reliable and never will. > But since you insist, let's ignore the unavoidable > problems, just make sure that a user who (already) > knows about --extra-cflags and --extra-ldflags and > remembers how he custom-compiled his library still > has a chance to compile FFmpeg with the library > even if he does not want to rely on pkg-config. We can't keep the current behaviour. We will need the users to add yet another option flag for this, probably in addition to a --pkg-config=/bin/false Basically, it will require them to change: --extra-cflags="-I/usr/local/include" --extra-ldflags="-L/usr/local/lib" Into: --extra-cflags="-I/usr/local/include" --extra-ldflags="-L/usr/locallib" --disable-pkg-config-detection (Yes, we want to make a distinction with --pkg-config=false) Or if they're going to change their command line anyway, they could just do: PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure ...and we wouldn't have to deal with such stupid hack. > If the build system chooses the wrong one of two > working libraries, this is the user's problem. > What I try to avoid is just that the user installs > a second version of the library because the system > library doesn't work but cannot select it because > the configure script blindly trusts the pkg-config > return value. He can select it through PKG_CONFIG_PATH instead of --extra-* options. No difference here. As I said several times, we can be more verbose about the pkg-config process; I don't mind sending a patch to print debug the detection process, like which libs with which flags is getting selected. [...] -- Clément B.
pgpKFtKhB0rj9.pgp
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
