[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ANN: ncurses-6.2-20211016

From: Thomas Dickey
Subject: Re: ANN: ncurses-6.2-20211016
Date: Mon, 25 Oct 2021 16:26:31 -0400
User-agent: Mutt/1.10.1 (2018-07-13)

On Mon, Oct 25, 2021 at 03:28:38PM -0400, Thomas Dickey wrote:
> hmm - the drawback that I knew of was that it would pick the first directory
> scanned (which isn't necessarily the one most often used).  Standardization
> across pkg-config's always been very poor, so I've machines with all of the
> choices being used by one package or another.
> To recap, the current issue was begun by a report that the existing
> (Debian-biased) predefined list of directories wasn't suitable.
> The manual page mentions
>        --variable=VARIABLENAME
>               This  returns the value of a variable defined in a package's .pc
>               file. Most packages define the variable "prefix",  for  example,
>               so you can say:
>                 $ pkg-config --variable=prefix glib-2.0
>                 /usr/
> and I overlooked its usefulness for the task (because the manual page doesn't
> point out the relationship between "pc_path", PKG_CONFIG_PATH and
> PKG_CONFIG_LIBDIR (actually reading the source code is needed to see the
> distinction between the latter two):
>        pc_path
>               The default search path used by pkg-config  when  searching  for
>               .pc files. This can be used in a query for the pkg-config module
>               itself itself:
>                 $ pkg-config --variable pc_path pkg-config
> Using "pkg-config --variable=pc_path" gives me this:
> /usr/local/lib/x86_64-linux-gnu/pkgconfig:/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/x86_64-linux-gnu/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig
> which needs some work to make it usable when developing a package.
> (I did read about "pkgconf" while working on the macro -- because I tested it
> with the BSDs which generally don't use pkg-config -- and the point was
> made in _its_ documentation that one should not actually count on it being
> compatible in fine details).
> fwiw, I test with machines older than 15 years as well...

for instance, this doesn't work on my Solaris10 machine (0.15.0),
so my configure script will have to check for availability of the feature.

Checking for when this feature was available in this form,
pkg-config's git log says it was added here:

commit e170895bc6241e933c6c6e85dc800fef5ed44615                                 
Author: Tollef Fog Heen <tfheen@err.no>                                         
Date:   Mon Mar 30 21:17:43 2009 +0200                                          
    2009-03-30  Tollef Fog Heen  <tfheen@err.no>                                
            * pkg.c (add_virtual_pkgconfig_package): Add pc_path as a variable  
            which you can use to get at the compiled-in PKG_CONFIG_PC_PATH.

which (for the upstream) makes it a little over 12 years.
For real use, I'd have to subtract a couple of years.

For pkgconf, it's a different story:

commit 7d89f659ffa45d381c3c4ee03c55f74635042829                                 
Author: Baptiste Daroussin <bapt@FreeBSD.org>                                   
Date:   Sun Jan 22 10:44:09 2017 +0100                                          
    Fix regression introduced in 7b39c38                                        
    now pkgconf --variable=pc_path pkg-config works

The feature itself was added here (9 years ago):

commit 111046f100a1a63b125494406351ce72a1a486bf                                 
Author: Ariadne Conill <ariadne@dereferenced.org>                               
Date:   Sun Jul 22 23:16:39 2012 -0500                                          
    pkg: add support for $(pc_path) variable for extracting PKG_DEFAULT_PATH

But this isn't the pkgconf bug reporting list; further discussion
of that aspect is off-topic.

Thomas E. Dickey <dickey@invisible-island.net>

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]