by Masahiro Yamada

[permalink] [raw]

Subject: Re: [PATCH v4] config: Allow kernel installation packaging to override pkg-config

On Fri, Apr 1, 2022 at 6:58 AM Chun-Tse Shao <[email protected]> wrote:
>
> On Tue, Mar 22, 2022 at 1:21 PM Chun-Tse Shao <[email protected]> wrote:
> >
> > On Tue, Mar 22, 2022 at 10:19:14AM -0700, Nick Desaulniers wrote:
> > > On Tue, Mar 22, 2022 at 12:44 AM Masahiro Yamada <[email protected]> wrote:
> > > >
> > > > On Wed, Mar 16, 2022 at 11:51 AM Chun-Tse Shao <[email protected]> wrote:
> > > > >
> > > > > Tue, Mar 08, 2022 at 01:01:45PM +0900, Masahiro Yamada wrote:
> > > > > > On Tue, Mar 8, 2022 at 7:50 AM Chun-Tse Shao <[email protected]> wrote:
> > > > > > >
> > > > > > > On Mon, Mar 07, 2022 at 10:17:17AM -0800, Nick Desaulniers wrote:
> > > > > > > > On Sun, Mar 6, 2022 at 2:39 PM Chun-Tse Shao <[email protected]> wrote:
> > > > > > > > >
> > > > > > > > > Add HOSTPKG_CONFIG to allow tooling that builds the kernel to override
> > > > > > > > > what pkg-config and parameters are used.
> > > > > > > >
> > > > > > > > Sorry, kind a late thought here for v4, but we don't seem to prefix
> > > > > > > > many other host side tools with HOST_, i.e. LEX, YACC, AWK, PERL,
> > > > > > > > PYTHON3, etc. Maybe just having the variable identifier be simply
> > > > > > > > PKGCONFIG rather than HOSTPKG_CONFIG then put it at the end of the
> > > > > > > > list in the top level Makefile after ZSTD (i.e. the list of host
> > > > > > > > tools)? There's HOST_ prefixes when there's more than one tool
> > > > > > > > involved (i.e. host compiler vs target compiler), but I suspect
> > > > > > > > there's no such distinction for the existing uses of pkg-config?
> > > > > > > >
> > > > > > > Thanks for your suggestion, Nick! Yes I think it makes sense with PKGCONFIG
> > > > > > > instead of HOSTPKG_CONFIG since there is only one tool involved. I will
> > > > > > > work on it and submit a new patch.
> > > > > > >
> > > > > >
> > > > > > Please hold on.
> > > > > >
> > > > > > I was also wondering what to do with the "HOST" prefix.
> > > > > >
> > > > > > Libraries are usually arch-dependent.
> > > > > > (in other words, pkg-config should return different library paths
> > > > > > for $(CC) and $(HOSTCC) )
> > > > > >
> > > > > > You already understood this, so you added "HOST" prefix.
> > > > > >
> > > > > >
> > > > > > Please let me take time for further discussion.
> > > > > > I will come back to this when I get some time.
> > > > > >
> > > > > >
> > > > >
> > > > > Hi Mashiro,
> > > > >
> > > > > I was wondering if you were able to look more into this.
> > > > >
> > > > > Thank you!
> > > > >
> > > > > -CT
> > > > >
> > > > > > In the meantime,
> > > > > > a8a5cd8b472ca20e5b8fa649c43b3756867322f8
> > > > > > as reference info if you have not seen it.
> > > > > >
> > > > > >
> > > > > > How many distros support something like
> > > > > > "aarch64-linux-gnu-pkg-config" ?
> > > > > >
> > > > > > Ubuntu 18.04 and 20.04 seem to support it.
> > > > > > I do not know for others.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > Sorry for the delay.
> > > > I am OK with the idea of allowing users to override the pkg-config command,
> > > > but I tend to take time before making a decision.
> > > >
> > > >
> > > >
> > > >
> > > > Does anybody have any insight / thoughts about the following points?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > [Q1] with/without "HOST" prefix
> > > >
> > > >
> > > > Apparently, "pkg-config" should return different libs/cflags
> > > > for $(CC) and $(HOSTCC).
> > > >
> > > > I think the non-prefixed macro name "PKG_CONFIG" should be
> > > > reserved for $(CC) (building for the target system).
> > >
> > > Ok. I retract my comment on v4 about removing the HOST prefix then.
> > >
> > > >
> > > > "HOSTPKG_CONFIG" looks unbalanced
> > > > due to the underscore.
> > > >
> > > > Perhaps, "HOST_PKG_CONFIG" might be better?
> > >
> > > I'm fine with HOSTPKG_CONFIG (what's in v4); follows the style of
> > > HOSTCC and HOSTCXX.
> > >
> >
> > Agree, it should follow the style of HOSTCC/HOSTCXX.
> >
> > > >
> > > >
> > > >
> > > >
> > > > [Q2] "pkg-config" vs "pkgconf"
> > > >
> > > > The traditional pkg-config implementation [1] is not actively
> > > > maintained these days.
> > > > The last commit was more than one year ago.
> > > >
> > > > The alternative one 'pkgconf' [2] is more active.
> > > >
> > > > In fact, Fedora already switched to 'pkgconf' [3].
> > > > Now 'pkg-config' is just a wrapper of 'pkgconf'.
> > > > Many distributions already support pkgconf.
> > > >
> > > >
> > > > I considered the shorter macro name "HOSTPKGCONF" and
> > > >
> > > > HOSTPKGCONF = pkgconf
> > > >
> > > > but I am not sure if this is the right decision.
> > > > Maybe we should stick to "PKG_CONFIG" / "HOST_PKG_CONFIG"
> > > > for the macro names.
> > > >
> > > >
> > > > [1] https://gitlab.freedesktop.org/pkg-config/pkg-config.git
> > > > [2] https://github.com/pkgconf/pkgconf.git
> > > > [3] https://fedoraproject.org/wiki/Changes/pkgconf_as_system_pkg-config_implementation
> > >
> > > If the folks sending this are working on CrOS, better find what's in
> > > their build system. Chun-Tse?
> > >
> > > (I feel like I'm behind the times again, like when `apt-get install`
> > > became old news in favor of `apt install`...)
> > >
> >
> > In Cros we only support pkg-config, and that is the reason we would like
> > to make this change in upstream.
> >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > [Q3] What is the trend of handling cross-compile by pkg-config (or pkgconf).
> > > >
> > > >
> > > > By default, pkg-config returns the libs/cflags for native builds.
> > > >
> > > > For cross builds, the search paths for the *.pc files must be changed
> > > > via the "PKG_CONFIG_LIBDIR" environment variable.
> > > >
> > > > To ease this, some distributions provide <triplet>-pkg-config
> > > > (for example, aarch64-linux-gnu-pkg-config).
> > > > This became the nationale for tools/build/feature/Makefile defining:
> > > >
> > > > PKG_CONFIG ?= $(CROSS_COMPILE)pkg-config
> > > >
> > > > But, this wrapper shell script is not always available.
> > > > I do not know how to do it with the LLVM tool suite.
> > > > I am not quite sure if this is the global solution.
> > > >
> > > >
> > > > These days, pkgconf supports another way, .personality file [4]
> > > > to specify the .pc search paths for cross builds.
> > > >
> > > > Is it reasonable to use an option to distinguish native / cross builds
> > > > and use the same macro "PKG_CONFIG = pkg-config" everywhere ?
> > > >
> > > >
> > > > [4] http://manpages.ubuntu.com/manpages/focal/en/man5/pkgconf-personality.5.html
> > >
> > > I'm not sure, but do we need to cross that bridge for this patch if
> > > it's just adding support for the HOST? No cross pkg-config necessary,
> > > yet. (Famous last words).
> >
> > Agree with Nick.
> >
> > Thanks,
> > CT
> > > --
> > > Thanks,
> > > ~Nick Desaulniers
>
> Hi Masahiro,
>
> I was wondering if you have any suggestions and thoughts.
>
> Thank you!
>
> -CT

Nobody was opposed to the macro name HOST_KG_CONFIG,
so I am fine.

I still see inconsistency in your patch, though.

For example, you did

echo >&2 "* 'make xconfig' requires '${HOSTPKG_CONFIG}'. Please
install it."

in scripts/kconfig/qconf-cfg.sh

but, you kept

echo >&2 "* 'make gconfig' requires 'pkg-config'. Please install it."

in scripts/kconfig/gconf-cfg.sh

Also, I prefer "kbuild:" to "config:"
for the patch subject.

--
Best Regards
Masahiro Yamada

2022-04-05 01:44:48

by Chun-Tse Shao

[permalink] [raw]

Subject: Re: [PATCH v4] config: Allow kernel installation packaging to override pkg-config

On Fri, Apr 01, 2022 at 11:42:13PM +0900, Masahiro Yamada wrote:
> On Fri, Apr 1, 2022 at 6:58 AM Chun-Tse Shao <[email protected]> wrote:
> >
> > On Tue, Mar 22, 2022 at 1:21 PM Chun-Tse Shao <[email protected]> wrote:
> > >
> > > On Tue, Mar 22, 2022 at 10:19:14AM -0700, Nick Desaulniers wrote:
> > > > On Tue, Mar 22, 2022 at 12:44 AM Masahiro Yamada <[email protected]> wrote:
> > > > >
> > > > > On Wed, Mar 16, 2022 at 11:51 AM Chun-Tse Shao <[email protected]> wrote:
> > > > > >
> > > > > > Tue, Mar 08, 2022 at 01:01:45PM +0900, Masahiro Yamada wrote:
> > > > > > > On Tue, Mar 8, 2022 at 7:50 AM Chun-Tse Shao <[email protected]> wrote:
> > > > > > > >
> > > > > > > > On Mon, Mar 07, 2022 at 10:17:17AM -0800, Nick Desaulniers wrote:
> > > > > > > > > On Sun, Mar 6, 2022 at 2:39 PM Chun-Tse Shao <[email protected]> wrote:
> > > > > > > > > >
> > > > > > > > > > Add HOSTPKG_CONFIG to allow tooling that builds the kernel to override
> > > > > > > > > > what pkg-config and parameters are used.
> > > > > > > > >
> > > > > > > > > Sorry, kind a late thought here for v4, but we don't seem to prefix
> > > > > > > > > many other host side tools with HOST_, i.e. LEX, YACC, AWK, PERL,
> > > > > > > > > PYTHON3, etc. Maybe just having the variable identifier be simply
> > > > > > > > > PKGCONFIG rather than HOSTPKG_CONFIG then put it at the end of the
> > > > > > > > > list in the top level Makefile after ZSTD (i.e. the list of host
> > > > > > > > > tools)? There's HOST_ prefixes when there's more than one tool
> > > > > > > > > involved (i.e. host compiler vs target compiler), but I suspect
> > > > > > > > > there's no such distinction for the existing uses of pkg-config?
> > > > > > > > >
> > > > > > > > Thanks for your suggestion, Nick! Yes I think it makes sense with PKGCONFIG
> > > > > > > > instead of HOSTPKG_CONFIG since there is only one tool involved. I will
> > > > > > > > work on it and submit a new patch.
> > > > > > > >
> > > > > > >
> > > > > > > Please hold on.
> > > > > > >
> > > > > > > I was also wondering what to do with the "HOST" prefix.
> > > > > > >
> > > > > > > Libraries are usually arch-dependent.
> > > > > > > (in other words, pkg-config should return different library paths
> > > > > > > for $(CC) and $(HOSTCC) )
> > > > > > >
> > > > > > > You already understood this, so you added "HOST" prefix.
> > > > > > >
> > > > > > >
> > > > > > > Please let me take time for further discussion.
> > > > > > > I will come back to this when I get some time.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > Hi Mashiro,
> > > > > >
> > > > > > I was wondering if you were able to look more into this.
> > > > > >
> > > > > > Thank you!
> > > > > >
> > > > > > -CT
> > > > > >
> > > > > > > In the meantime,
> > > > > > > a8a5cd8b472ca20e5b8fa649c43b3756867322f8
> > > > > > > as reference info if you have not seen it.
> > > > > > >
> > > > > > >
> > > > > > > How many distros support something like
> > > > > > > "aarch64-linux-gnu-pkg-config" ?
> > > > > > >
> > > > > > > Ubuntu 18.04 and 20.04 seem to support it.
> > > > > > > I do not know for others.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > Sorry for the delay.
> > > > > I am OK with the idea of allowing users to override the pkg-config command,
> > > > > but I tend to take time before making a decision.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Does anybody have any insight / thoughts about the following points?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > [Q1] with/without "HOST" prefix
> > > > >
> > > > >
> > > > > Apparently, "pkg-config" should return different libs/cflags
> > > > > for $(CC) and $(HOSTCC).
> > > > >
> > > > > I think the non-prefixed macro name "PKG_CONFIG" should be
> > > > > reserved for $(CC) (building for the target system).
> > > >
> > > > Ok. I retract my comment on v4 about removing the HOST prefix then.
> > > >
> > > > >
> > > > > "HOSTPKG_CONFIG" looks unbalanced
> > > > > due to the underscore.
> > > > >
> > > > > Perhaps, "HOST_PKG_CONFIG" might be better?
> > > >
> > > > I'm fine with HOSTPKG_CONFIG (what's in v4); follows the style of
> > > > HOSTCC and HOSTCXX.
> > > >
> > >
> > > Agree, it should follow the style of HOSTCC/HOSTCXX.
> > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > [Q2] "pkg-config" vs "pkgconf"
> > > > >
> > > > > The traditional pkg-config implementation [1] is not actively
> > > > > maintained these days.
> > > > > The last commit was more than one year ago.
> > > > >
> > > > > The alternative one 'pkgconf' [2] is more active.
> > > > >
> > > > > In fact, Fedora already switched to 'pkgconf' [3].
> > > > > Now 'pkg-config' is just a wrapper of 'pkgconf'.
> > > > > Many distributions already support pkgconf.
> > > > >
> > > > >
> > > > > I considered the shorter macro name "HOSTPKGCONF" and
> > > > >
> > > > > HOSTPKGCONF = pkgconf
> > > > >
> > > > > but I am not sure if this is the right decision.
> > > > > Maybe we should stick to "PKG_CONFIG" / "HOST_PKG_CONFIG"
> > > > > for the macro names.
> > > > >
> > > > >
> > > > > [1] https://gitlab.freedesktop.org/pkg-config/pkg-config.git
> > > > > [2] https://github.com/pkgconf/pkgconf.git
> > > > > [3] https://fedoraproject.org/wiki/Changes/pkgconf_as_system_pkg-config_implementation
> > > >
> > > > If the folks sending this are working on CrOS, better find what's in
> > > > their build system. Chun-Tse?
> > > >
> > > > (I feel like I'm behind the times again, like when `apt-get install`
> > > > became old news in favor of `apt install`...)
> > > >
> > >
> > > In Cros we only support pkg-config, and that is the reason we would like
> > > to make this change in upstream.
> > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > [Q3] What is the trend of handling cross-compile by pkg-config (or pkgconf).
> > > > >
> > > > >
> > > > > By default, pkg-config returns the libs/cflags for native builds.
> > > > >
> > > > > For cross builds, the search paths for the *.pc files must be changed
> > > > > via the "PKG_CONFIG_LIBDIR" environment variable.
> > > > >
> > > > > To ease this, some distributions provide <triplet>-pkg-config
> > > > > (for example, aarch64-linux-gnu-pkg-config).
> > > > > This became the nationale for tools/build/feature/Makefile defining:
> > > > >
> > > > > PKG_CONFIG ?= $(CROSS_COMPILE)pkg-config
> > > > >
> > > > > But, this wrapper shell script is not always available.
> > > > > I do not know how to do it with the LLVM tool suite.
> > > > > I am not quite sure if this is the global solution.
> > > > >
> > > > >
> > > > > These days, pkgconf supports another way, .personality file [4]
> > > > > to specify the .pc search paths for cross builds.
> > > > >
> > > > > Is it reasonable to use an option to distinguish native / cross builds
> > > > > and use the same macro "PKG_CONFIG = pkg-config" everywhere ?
> > > > >
> > > > >
> > > > > [4] http://manpages.ubuntu.com/manpages/focal/en/man5/pkgconf-personality.5.html
> > > >
> > > > I'm not sure, but do we need to cross that bridge for this patch if
> > > > it's just adding support for the HOST? No cross pkg-config necessary,
> > > > yet. (Famous last words).
> > >
> > > Agree with Nick.
> > >
> > > Thanks,
> > > CT
> > > > --
> > > > Thanks,
> > > > ~Nick Desaulniers
> >
> > Hi Masahiro,
> >
> > I was wondering if you have any suggestions and thoughts.
> >
> > Thank you!
> >
> > -CT
>
>
> Nobody was opposed to the macro name HOST_KG_CONFIG,
> so I am fine.
>
>
>
> I still see inconsistency in your patch, though.
>
>
> For example, you did
>
> echo >&2 "* 'make xconfig' requires '${HOSTPKG_CONFIG}'. Please
> install it."
>
> in scripts/kconfig/qconf-cfg.sh
>
>
> but, you kept
>
> echo >&2 "* 'make gconfig' requires 'pkg-config'. Please install it."
>
> in scripts/kconfig/gconf-cfg.sh
>
>
>
>
> Also, I prefer "kbuild:" to "config:"
> for the patch subject.
>
>
> --
> Best Regards
> Masahiro Yamada

Hi Masahiro,

Thanks for your review and suggestions! I sent a new patch for the fix:
https://lore.kernel.org/all/[email protected]/
Just wondering if I should also do the same change for the pkg-config in
comment in kconfig shell scripts?

Thanks,
CT