[FFmpeg-devel] [PATCH 2/3] build: rely on pkg-config for libx264 probing
u at pkh.me
Thu Aug 21 13:49:39 CEST 2014
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
- 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
Basically, it will require them to change:
(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
...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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 473 bytes
Desc: not available
More information about the ffmpeg-devel