[OpenWrt-Devel,PATCHv2,1/3] tools/pkg-config: Replace with pkgconf

pkgconf is a newer, actively maintained implementation of pkg-config that
supports more aspects of the pkg-config file specification and provides a
library interface that applications can use to incorporate intelligent
handling of pkg-config files into themselves (such as build file
generators, IDEs, and compilers). Through its pkg-config compatibility
interface (activated when it is run as "pkg-config"), it also can
completely replace the original implementation.

It is also lighterweight and does not require glib2, as pkg-config does.

On other distros, pkgconf is symlinked to pkg-config. For simplicity here,
it is renamed to pkg-config.real, as in the original package.

Initial results have been positive. As before, pkgconf works as long as
the pkg-config files point to the proper paths.

Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
 tools/Makefile                                |  6 +++---
 tools/{pkg-config => pkgconf}/Makefile        | 20 +++++++------------
 .../{pkg-config => pkgconf}/files/pkg-config  |  0
 3 files changed, 10 insertions(+), 16 deletions(-)
 rename tools/{pkg-config => pkgconf}/Makefile (54%)
 rename tools/{pkg-config => pkgconf}/files/pkg-config (100%)

Rosen Penev <rosenp@gmail.com> [2019-11-28 11:19:31]:

> pkgconf is a newer, actively maintained implementation of pkg-config

I'm wondering if that `actively maintained` part still holds true.

-- ynezz

On Wed, Dec 25, 2019 at 3:17 AM Petr Štetiar <ynezz@true.cz> wrote:
>
> Rosen Penev <rosenp@gmail.com> [2019-11-28 11:19:31]:
>
> > pkgconf is a newer, actively maintained implementation of pkg-config
>
> I'm wondering if that `actively maintained` part still holds true.
It does. The team has management issues it seems. They've publicly
stated they want to move away from GitHub:
https://github.com/pkgconf/pkgconf.github.io/issues/1

So you would think based on the URL of the download that development
moved here: https://git.dereferenced.org/pkgconf/pkgconf#

But there's also a third place where development seems to have moved:
https://git.sr.ht/~kaniini/pkgconf/log

Seems it's a mess.
>
> -- ynezz

Rosen Penev <rosenp@gmail.com> [2019-12-25 12:51:33]:

> On Wed, Dec 25, 2019 at 3:17 AM Petr Štetiar <ynezz@true.cz> wrote:
> >
> > Rosen Penev <rosenp@gmail.com> [2019-11-28 11:19:31]:
> >
> > > pkgconf is a newer, actively maintained implementation of pkg-config
> >
> > I'm wondering if that `actively maintained` part still holds true.
>
> It does. The team has management issues it seems. They've publicly
> stated they want to move away from GitHub:
> https://github.com/pkgconf/pkgconf.github.io/issues/1
> 
> So you would think based on the URL of the download that development
> moved here: https://git.dereferenced.org/pkgconf/pkgconf#
> 
> But there's also a third place where development seems to have moved:
> https://git.sr.ht/~kaniini/pkgconf/log
> 
> Seems it's a mess.

So how to sort this out?

I'm simply in favor of keeping the current pkg-config, because the suggested
replacement doesn't seem like a worth considering yet, but maybe I read it
wrong.

-- ynezz

On Fri, Feb 28, 2020 at 2:03 AM Petr Štetiar <ynezz@true.cz> wrote:
>
> Rosen Penev <rosenp@gmail.com> [2019-12-25 12:51:33]:
>
> > On Wed, Dec 25, 2019 at 3:17 AM Petr Štetiar <ynezz@true.cz> wrote:
> > >
> > > Rosen Penev <rosenp@gmail.com> [2019-11-28 11:19:31]:
> > >
> > > > pkgconf is a newer, actively maintained implementation of pkg-config
> > >
> > > I'm wondering if that `actively maintained` part still holds true.
> >
> > It does. The team has management issues it seems. They've publicly
> > stated they want to move away from GitHub:
> > https://github.com/pkgconf/pkgconf.github.io/issues/1
> >
> > So you would think based on the URL of the download that development
> > moved here: https://git.dereferenced.org/pkgconf/pkgconf#
> >
> > But there's also a third place where development seems to have moved:
> > https://git.sr.ht/~kaniini/pkgconf/log
> >
> > Seems it's a mess.
>
> So how to sort this out?
>
> I'm simply in favor of keeping the current pkg-config, because the suggested
> replacement doesn't seem like a worth considering yet, but maybe I read it
> wrong.
It's more portable and smaller. And as stated, it is still fairly active.
>
> -- ynezz

Rosen Penev <rosenp@gmail.com> [2020-02-28 20:12:45]:

Hi,

> It's more portable and smaller. And as stated, it is still fairly active.

Jo has today brought following issue to my attention:

## pkgconf
 $ PATH=$(pwd)/staging_dir/host/bin:$PATH STAGING_PREFIX=$(pwd)/staging_dir/host PKG_CONFIG_PATH=$(pwd)/staging_dir/host/lib/pkgconfig PKG_CONFIG_LIBDIR=$(pwd)/staging_dir/host/lib/pkgconfig pkg-config libelf --libs
 -lelf

## pkg-config

 $ PATH=$(pwd)/staging_dir/host/bin:$PATH STAGING_PREFIX=$(pwd)/staging_dir/host PKG_CONFIG_PATH=$(pwd)/staging_dir/host/lib/pkgconfig PKG_CONFIG_LIBDIR=$(pwd)/staging_dir/host/lib/pkgconfig pkg-config libelf --libs
 -L/home/jow/devel/lede/staging.git/staging_dir/host/lib -lelf

So it looks like pkgconf is filtering out some library paths, causing for
example following issues:

 make[5]: *** No rule to make target 'tools/objtool/objtool', needed by '/home/jow/devel/lede/staging.git/build_dir/target-x86_64_musl/linux-x86_64/siit-1.2/siit.o'.  Stop.

< jow> the main kernel build will skip building objtool (and forcibly disable CONFIG_STACK_VALIDATION) because it cannot link libelf
< jow> any external kmod will assume CONFIG_STACK_VALIDATION is enabled and kbuild will try to invoke objtool which doesn't exist in the precompiled kernel soure tree

Possibly caused by:

 ## linker flags optimization

 As previously mentioned, pkgconf makes optimizations to the linker flags in
 both the case of static and shared linking in order to avoid overlinking
 binaries and also simplifies the `CFLAGS` and `LIBS` output of the pkgconf
 tool for improved readability.

Ref: https://github.com/openwrt/openwrt/pull/2832

-- ynezz

On Fri, Mar 13, 2020 at 7:33 AM Petr Štetiar <ynezz@true.cz> wrote:
>
> Rosen Penev <rosenp@gmail.com> [2020-02-28 20:12:45]:
>
> Hi,
>
> > It's more portable and smaller. And as stated, it is still fairly active.
>
> Jo has today brought following issue to my attention:
>
> ## pkgconf
>  $ PATH=$(pwd)/staging_dir/host/bin:$PATH STAGING_PREFIX=$(pwd)/staging_dir/host PKG_CONFIG_PATH=$(pwd)/staging_dir/host/lib/pkgconfig PKG_CONFIG_LIBDIR=$(pwd)/staging_dir/host/lib/pkgconfig pkg-config libelf --libs
>  -lelf
>
> ## pkg-config
>
>  $ PATH=$(pwd)/staging_dir/host/bin:$PATH STAGING_PREFIX=$(pwd)/staging_dir/host PKG_CONFIG_PATH=$(pwd)/staging_dir/host/lib/pkgconfig PKG_CONFIG_LIBDIR=$(pwd)/staging_dir/host/lib/pkgconfig pkg-config libelf --libs
>  -L/home/jow/devel/lede/staging.git/staging_dir/host/lib -lelf
>
> So it looks like pkgconf is filtering out some library paths, causing for
> example following issues:
>
>  make[5]: *** No rule to make target 'tools/objtool/objtool', needed by '/home/jow/devel/lede/staging.git/build_dir/target-x86_64_musl/linux-x86_64/siit-1.2/siit.o'.  Stop.
>
> < jow> the main kernel build will skip building objtool (and forcibly disable CONFIG_STACK_VALIDATION) because it cannot link libelf
> < jow> any external kmod will assume CONFIG_STACK_VALIDATION is enabled and kbuild will try to invoke objtool which doesn't exist in the precompiled kernel soure tree
>
> Possibly caused by:
>
>  ## linker flags optimization
>
>  As previously mentioned, pkgconf makes optimizations to the linker flags in
>  both the case of static and shared linking in order to avoid overlinking
>  binaries and also simplifies the `CFLAGS` and `LIBS` output of the pkgconf
>  tool for improved readability.
>
> Ref: https://github.com/openwrt/openwrt/pull/2832
Never seen this. Then again, I've only dealt with target packages.
>
> -- ynezz