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. > 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. > 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. 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. 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. Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
