[FFmpeg-devel] [PATCH 2/3] build: rely on pkg-config for libx264 probing

[Clément Bœsch]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140821/3730f389/attachment.asc>