[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pkg-config "Requires" fields and propagated inputs
From: |
Ludovic Courtès |
Subject: |
Re: pkg-config "Requires" fields and propagated inputs |
Date: |
Tue, 31 Mar 2015 14:14:27 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) |
address@hidden (Taylan Ulrich "Bayırlı/Kammer") skribis:
> address@hidden (Taylan Ulrich "Bayırlı/Kammer") writes:
>
>> P.S.: I'll see if I can write a tool that compares the union of the
>> Requires[.private] fields of all .pc files in a package to the package's
>> propagated inputs, so we can detect mismatches automatically.
>
> So here's a first version.
>
> https://notabug.org/taylanub/guix/src/master/missing-propagated-inputs.scm
>
> Sample output from my system is below; evidently it's open to some
> improvement.
Nice!
> Maybe I should try to move to a strategy that calls pkg-config instead
> of parsing the files in Guile, but it might be nontrivial to get the
> PKG_CONFIG_PATH right for each call, and doing many execs might be too
> slow, so I'll first see how much further I can get with this strategy.
Yeah forking would be slow; parsing sounds good. However, the ‘satisfy’
predicates could be based on actual package contents (when available):
looking for actual .pc files and libraries.
> $ ./pre-inst-env guile -c '((@ (guix missing-propagated-inputs)
> print-missing-propagated-inputs))'
> "fftw": ("-lfftw3" "-lm")
> "fftwf": ("-lfftw3f" "-lm")
This is a false positives: -lfftw3* is actually provided by the package
itself, and -lm is part of libc, so it’s always found (libc libraries
will have to be special-cased.)
> "apr": ("-ldl" "-lpthread" "-lcrypt" "-lrt" "-lapr-${APR_MAJOR_VERSION}")
Again libc libraries, and the library of APR itself. Problem is that
this one requires almost a full reimplementation of pkg-config, to be
able to do variable substitution (probably not insurmountable though.)
> "guile": ("-lgc" "-lffi")
guile-2.0.pc has this:
Libs: -L${libdir} -lguile-2.0
-L/gnu/store/dxfv00pgmnhxkj5jh3yxyp0q94l6i2ch-libgc-7.4.2/lib -lgc
So here -lgc is a false positive: libgc is found by virtue of the -L
flag.
‘-lffi’ only appears in ‘Libs.private’ (static linking) so I would just
ignore it.
It looks like there are 3 classes of false positives here that would
need to be addressed to make the report more directly readable.
WDYT?
Thank you!
Ludo’.