| Message ID | 20220306223016.2239094-1-ctshao@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v4] config: Allow kernel installation packaging to override pkg-config | expand |
On Sun, Mar 6, 2022 at 2:39 PM Chun-Tse Shao <ctshao@google.com> 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? Otherwise, sorry for opening a bikeshed so late; this patch still LGTM. Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> > > Signed-off-by: Chun-Tse Shao <ctshao@google.com> > --- > Changes from v3: https://lore.kernel.org/all/20220304041449.939308-1-ctshao@google.com > - Dereference variables using {} instead of () in shell scripts > - Tested with make allmodconfig > > Changes from v2: https://lore.kernel.org/all/20220302193638.11034-1-ctshao@google.com/ > - Fix more open coded instance of pkg-config in scripts and certs > - Tested with make allmodconfig > > Changes from v1: https://lore.kernel.org/all/20220301230629.1892828-1-ctshao@google.com/ > - Make the commit message more clearer. > --- > Makefile | 3 ++- > certs/Makefile | 4 ++-- > scripts/Makefile | 4 ++-- > scripts/dtc/Makefile | 6 +++--- > scripts/kconfig/gconf-cfg.sh | 10 +++++----- > scripts/kconfig/mconf-cfg.sh | 14 +++++++------- > scripts/kconfig/nconf-cfg.sh | 14 +++++++------- > scripts/kconfig/qconf-cfg.sh | 14 +++++++------- > tools/objtool/Makefile | 4 ++-- > 9 files changed, 37 insertions(+), 36 deletions(-) > > diff --git a/Makefile b/Makefile > index daeb5c88b50b..f6c5bef7e141 100644 > --- a/Makefile > +++ b/Makefile > @@ -430,6 +430,7 @@ else > HOSTCC = gcc > HOSTCXX = g++ > endif > +HOSTPKG_CONFIG = pkg-config > > export KBUILD_USERCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes \ > -O2 -fomit-frame-pointer -std=gnu89 > @@ -525,7 +526,7 @@ KBUILD_LDFLAGS_MODULE := > KBUILD_LDFLAGS := > CLANG_FLAGS := > > -export ARCH SRCARCH CONFIG_SHELL BASH HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE LD CC > +export ARCH SRCARCH CONFIG_SHELL BASH HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE LD CC HOSTPKG_CONFIG > export CPP AR NM STRIP OBJCOPY OBJDUMP READELF PAHOLE RESOLVE_BTFIDS LEX YACC AWK INSTALLKERNEL > export PERL PYTHON3 CHECK CHECKFLAGS MAKE UTS_MACHINE HOSTCXX > export KGZIP KBZIP2 KLZOP LZMA LZ4 XZ ZSTD > diff --git a/certs/Makefile b/certs/Makefile > index 3ea7fe60823f..fa540d14ef2d 100644 > --- a/certs/Makefile > +++ b/certs/Makefile > @@ -89,5 +89,5 @@ targets += x509_revocation_list > > hostprogs := extract-cert > > -HOSTCFLAGS_extract-cert.o = $(shell pkg-config --cflags libcrypto 2> /dev/null) > -HOSTLDLIBS_extract-cert = $(shell pkg-config --libs libcrypto 2> /dev/null || echo -lcrypto) > +HOSTCFLAGS_extract-cert.o = $(shell $(HOSTPKG_CONFIG) --cflags libcrypto 2> /dev/null) > +HOSTLDLIBS_extract-cert = $(shell $(HOSTPKG_CONFIG) --libs libcrypto 2> /dev/null || echo -lcrypto) > diff --git a/scripts/Makefile b/scripts/Makefile > index ce5aa9030b74..f084f08ed176 100644 > --- a/scripts/Makefile > +++ b/scripts/Makefile > @@ -14,8 +14,8 @@ hostprogs-always-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert > HOSTCFLAGS_sorttable.o = -I$(srctree)/tools/include > HOSTLDLIBS_sorttable = -lpthread > HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include > -HOSTCFLAGS_sign-file.o = $(shell pkg-config --cflags libcrypto 2> /dev/null) > -HOSTLDLIBS_sign-file = $(shell pkg-config --libs libcrypto 2> /dev/null || echo -lcrypto) > +HOSTCFLAGS_sign-file.o = $(shell $(HOSTPKG_CONFIG) --cflags libcrypto 2> /dev/null) > +HOSTLDLIBS_sign-file = $(shell $(HOSTPKG_CONFIG) --libs libcrypto 2> /dev/null || echo -lcrypto) > > ifdef CONFIG_UNWINDER_ORC > ifeq ($(ARCH),x86_64) > diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile > index 95aaf7431bff..743fc08827ea 100644 > --- a/scripts/dtc/Makefile > +++ b/scripts/dtc/Makefile > @@ -18,7 +18,7 @@ fdtoverlay-objs := $(libfdt) fdtoverlay.o util.o > # Source files need to get at the userspace version of libfdt_env.h to compile > HOST_EXTRACFLAGS += -I $(srctree)/$(src)/libfdt > > -ifeq ($(shell pkg-config --exists yaml-0.1 2>/dev/null && echo yes),) > +ifeq ($(shell $(HOSTPKG_CONFIG) --exists yaml-0.1 2>/dev/null && echo yes),) > ifneq ($(CHECK_DT_BINDING)$(CHECK_DTBS),) > $(error dtc needs libyaml for DT schema validation support. \ > Install the necessary libyaml development package.) > @@ -27,9 +27,9 @@ HOST_EXTRACFLAGS += -DNO_YAML > else > dtc-objs += yamltree.o > # To include <yaml.h> installed in a non-default path > -HOSTCFLAGS_yamltree.o := $(shell pkg-config --cflags yaml-0.1) > +HOSTCFLAGS_yamltree.o := $(shell $(HOSTPKG_CONFIG) --cflags yaml-0.1) > # To link libyaml installed in a non-default path > -HOSTLDLIBS_dtc := $(shell pkg-config yaml-0.1 --libs) > +HOSTLDLIBS_dtc := $(shell $(HOSTPKG_CONFIG) yaml-0.1 --libs) > endif > > # Generated files need one more search path to include headers in source tree > diff --git a/scripts/kconfig/gconf-cfg.sh b/scripts/kconfig/gconf-cfg.sh > index 480ecd8b9f41..4da4e39dcb53 100755 > --- a/scripts/kconfig/gconf-cfg.sh > +++ b/scripts/kconfig/gconf-cfg.sh > @@ -3,14 +3,14 @@ > > PKG="gtk+-2.0 gmodule-2.0 libglade-2.0" > > -if [ -z "$(command -v pkg-config)" ]; then > +if [ -z "$(command -v ${HOSTPKG_CONFIG})" ]; then > echo >&2 "*" > echo >&2 "* 'make gconfig' requires 'pkg-config'. Please install it." > echo >&2 "*" > exit 1 > fi > > -if ! pkg-config --exists $PKG; then > +if ! ${HOSTPKG_CONFIG} --exists $PKG; then > echo >&2 "*" > echo >&2 "* Unable to find the GTK+ installation. Please make sure that" > echo >&2 "* the GTK+ 2.0 development package is correctly installed." > @@ -19,12 +19,12 @@ if ! pkg-config --exists $PKG; then > exit 1 > fi > > -if ! pkg-config --atleast-version=2.0.0 gtk+-2.0; then > +if ! ${HOSTPKG_CONFIG} --atleast-version=2.0.0 gtk+-2.0; then > echo >&2 "*" > echo >&2 "* GTK+ is present but version >= 2.0.0 is required." > echo >&2 "*" > exit 1 > fi > > -echo cflags=\"$(pkg-config --cflags $PKG)\" > -echo libs=\"$(pkg-config --libs $PKG)\" > +echo cflags=\"$(${HOSTPKG_CONFIG} --cflags $PKG)\" > +echo libs=\"$(${HOSTPKG_CONFIG} --libs $PKG)\" > diff --git a/scripts/kconfig/mconf-cfg.sh b/scripts/kconfig/mconf-cfg.sh > index b520e407a8eb..05837ed07fbd 100755 > --- a/scripts/kconfig/mconf-cfg.sh > +++ b/scripts/kconfig/mconf-cfg.sh > @@ -4,16 +4,16 @@ > PKG="ncursesw" > PKG2="ncurses" > > -if [ -n "$(command -v pkg-config)" ]; then > - if pkg-config --exists $PKG; then > - echo cflags=\"$(pkg-config --cflags $PKG)\" > - echo libs=\"$(pkg-config --libs $PKG)\" > +if [ -n "$(command -v ${HOSTPKG_CONFIG})" ]; then > + if ${HOSTPKG_CONFIG} --exists $PKG; then > + echo cflags=\"$(${HOSTPKG_CONFIG} --cflags $PKG)\" > + echo libs=\"$(${HOSTPKG_CONFIG} --libs $PKG)\" > exit 0 > fi > > - if pkg-config --exists $PKG2; then > - echo cflags=\"$(pkg-config --cflags $PKG2)\" > - echo libs=\"$(pkg-config --libs $PKG2)\" > + if ${HOSTPKG_CONFIG} --exists $PKG2; then > + echo cflags=\"$(${HOSTPKG_CONFIG} --cflags $PKG2)\" > + echo libs=\"$(${HOSTPKG_CONFIG} --libs $PKG2)\" > exit 0 > fi > fi > diff --git a/scripts/kconfig/nconf-cfg.sh b/scripts/kconfig/nconf-cfg.sh > index c212255070c0..e8d8f12d93ac 100755 > --- a/scripts/kconfig/nconf-cfg.sh > +++ b/scripts/kconfig/nconf-cfg.sh > @@ -4,16 +4,16 @@ > PKG="ncursesw menuw panelw" > PKG2="ncurses menu panel" > > -if [ -n "$(command -v pkg-config)" ]; then > - if pkg-config --exists $PKG; then > - echo cflags=\"$(pkg-config --cflags $PKG)\" > - echo libs=\"$(pkg-config --libs $PKG)\" > +if [ -n "$(command -v ${HOSTPKG_CONFIG})" ]; then > + if ${HOSTPKG_CONFIG} --exists $PKG; then > + echo cflags=\"$(${HOSTPKG_CONFIG} --cflags $PKG)\" > + echo libs=\"$(${HOSTPKG_CONFIG} --libs $PKG)\" > exit 0 > fi > > - if pkg-config --exists $PKG2; then > - echo cflags=\"$(pkg-config --cflags $PKG2)\" > - echo libs=\"$(pkg-config --libs $PKG2)\" > + if ${HOSTPKG_CONFIG} --exists $PKG2; then > + echo cflags=\"$(${HOSTPKG_CONFIG} --cflags $PKG2)\" > + echo libs=\"$(${HOSTPKG_CONFIG} --libs $PKG2)\" > exit 0 > fi > fi > diff --git a/scripts/kconfig/qconf-cfg.sh b/scripts/kconfig/qconf-cfg.sh > index fa564cd795b7..9b695e5cd9b3 100755 > --- a/scripts/kconfig/qconf-cfg.sh > +++ b/scripts/kconfig/qconf-cfg.sh > @@ -3,22 +3,22 @@ > > PKG="Qt5Core Qt5Gui Qt5Widgets" > > -if [ -z "$(command -v pkg-config)" ]; then > +if [ -z "$(command -v ${HOSTPKG_CONFIG})" ]; then > echo >&2 "*" > - echo >&2 "* 'make xconfig' requires 'pkg-config'. Please install it." > + echo >&2 "* 'make xconfig' requires '${HOSTPKG_CONFIG}'. Please install it." > echo >&2 "*" > exit 1 > fi > > -if pkg-config --exists $PKG; then > - echo cflags=\"-std=c++11 -fPIC $(pkg-config --cflags $PKG)\" > - echo libs=\"$(pkg-config --libs $PKG)\" > - echo moc=\"$(pkg-config --variable=host_bins Qt5Core)/moc\" > +if ${HOSTPKG_CONFIG} --exists $PKG; then > + echo cflags=\"-std=c++11 -fPIC $(${HOSTPKG_CONFIG} --cflags $PKG)\" > + echo libs=\"$(${HOSTPKG_CONFIG} --libs $PKG)\" > + echo moc=\"$(${HOSTPKG_CONFIG} --variable=host_bins Qt5Core)/moc\" > exit 0 > fi > > echo >&2 "*" > -echo >&2 "* Could not find Qt5 via pkg-config." > +echo >&2 "* Could not find Qt5 via ${HOSTPKG_CONFIG}." > echo >&2 "* Please install Qt5 and make sure it's in PKG_CONFIG_PATH" > echo >&2 "*" > exit 1 > diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile > index 92ce4fce7bc7..549acc5859e9 100644 > --- a/tools/objtool/Makefile > +++ b/tools/objtool/Makefile > @@ -19,8 +19,8 @@ LIBSUBCMD = $(LIBSUBCMD_OUTPUT)libsubcmd.a > OBJTOOL := $(OUTPUT)objtool > OBJTOOL_IN := $(OBJTOOL)-in.o > > -LIBELF_FLAGS := $(shell pkg-config libelf --cflags 2>/dev/null) > -LIBELF_LIBS := $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf) > +LIBELF_FLAGS := $(shell $(HOSTPKG_CONFIG) libelf --cflags 2>/dev/null) > +LIBELF_LIBS := $(shell $(HOSTPKG_CONFIG) libelf --libs 2>/dev/null || echo -lelf) > > all: $(OBJTOOL) > > -- > 2.35.1.616.g0bdcbb4464-goog >
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 <ctshao@google.com> 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. -CT > Otherwise, sorry for opening a bikeshed so late; this patch still LGTM. > Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> > > > > > Signed-off-by: Chun-Tse Shao <ctshao@google.com> > > --- > > Changes from v3: https://lore.kernel.org/all/20220304041449.939308-1-ctshao@google.com > > - Dereference variables using {} instead of () in shell scripts > > - Tested with make allmodconfig > > > > Changes from v2: https://lore.kernel.org/all/20220302193638.11034-1-ctshao@google.com/ > > - Fix more open coded instance of pkg-config in scripts and certs > > - Tested with make allmodconfig > > > > Changes from v1: https://lore.kernel.org/all/20220301230629.1892828-1-ctshao@google.com/ > > - Make the commit message more clearer. > > --- > > Makefile | 3 ++- > > certs/Makefile | 4 ++-- > > scripts/Makefile | 4 ++-- > > scripts/dtc/Makefile | 6 +++--- > > scripts/kconfig/gconf-cfg.sh | 10 +++++----- > > scripts/kconfig/mconf-cfg.sh | 14 +++++++------- > > scripts/kconfig/nconf-cfg.sh | 14 +++++++------- > > scripts/kconfig/qconf-cfg.sh | 14 +++++++------- > > tools/objtool/Makefile | 4 ++-- > > 9 files changed, 37 insertions(+), 36 deletions(-) > > > > diff --git a/Makefile b/Makefile > > index daeb5c88b50b..f6c5bef7e141 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -430,6 +430,7 @@ else > > HOSTCC = gcc > > HOSTCXX = g++ > > endif > > +HOSTPKG_CONFIG = pkg-config > > > > export KBUILD_USERCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes \ > > -O2 -fomit-frame-pointer -std=gnu89 > > @@ -525,7 +526,7 @@ KBUILD_LDFLAGS_MODULE := > > KBUILD_LDFLAGS := > > CLANG_FLAGS := > > > > -export ARCH SRCARCH CONFIG_SHELL BASH HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE LD CC > > +export ARCH SRCARCH CONFIG_SHELL BASH HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE LD CC HOSTPKG_CONFIG > > export CPP AR NM STRIP OBJCOPY OBJDUMP READELF PAHOLE RESOLVE_BTFIDS LEX YACC AWK INSTALLKERNEL > > export PERL PYTHON3 CHECK CHECKFLAGS MAKE UTS_MACHINE HOSTCXX > > export KGZIP KBZIP2 KLZOP LZMA LZ4 XZ ZSTD > > diff --git a/certs/Makefile b/certs/Makefile > > index 3ea7fe60823f..fa540d14ef2d 100644 > > --- a/certs/Makefile > > +++ b/certs/Makefile > > @@ -89,5 +89,5 @@ targets += x509_revocation_list > > > > hostprogs := extract-cert > > > > -HOSTCFLAGS_extract-cert.o = $(shell pkg-config --cflags libcrypto 2> /dev/null) > > -HOSTLDLIBS_extract-cert = $(shell pkg-config --libs libcrypto 2> /dev/null || echo -lcrypto) > > +HOSTCFLAGS_extract-cert.o = $(shell $(HOSTPKG_CONFIG) --cflags libcrypto 2> /dev/null) > > +HOSTLDLIBS_extract-cert = $(shell $(HOSTPKG_CONFIG) --libs libcrypto 2> /dev/null || echo -lcrypto) > > diff --git a/scripts/Makefile b/scripts/Makefile > > index ce5aa9030b74..f084f08ed176 100644 > > --- a/scripts/Makefile > > +++ b/scripts/Makefile > > @@ -14,8 +14,8 @@ hostprogs-always-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert > > HOSTCFLAGS_sorttable.o = -I$(srctree)/tools/include > > HOSTLDLIBS_sorttable = -lpthread > > HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include > > -HOSTCFLAGS_sign-file.o = $(shell pkg-config --cflags libcrypto 2> /dev/null) > > -HOSTLDLIBS_sign-file = $(shell pkg-config --libs libcrypto 2> /dev/null || echo -lcrypto) > > +HOSTCFLAGS_sign-file.o = $(shell $(HOSTPKG_CONFIG) --cflags libcrypto 2> /dev/null) > > +HOSTLDLIBS_sign-file = $(shell $(HOSTPKG_CONFIG) --libs libcrypto 2> /dev/null || echo -lcrypto) > > > > ifdef CONFIG_UNWINDER_ORC > > ifeq ($(ARCH),x86_64) > > diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile > > index 95aaf7431bff..743fc08827ea 100644 > > --- a/scripts/dtc/Makefile > > +++ b/scripts/dtc/Makefile > > @@ -18,7 +18,7 @@ fdtoverlay-objs := $(libfdt) fdtoverlay.o util.o > > # Source files need to get at the userspace version of libfdt_env.h to compile > > HOST_EXTRACFLAGS += -I $(srctree)/$(src)/libfdt > > > > -ifeq ($(shell pkg-config --exists yaml-0.1 2>/dev/null && echo yes),) > > +ifeq ($(shell $(HOSTPKG_CONFIG) --exists yaml-0.1 2>/dev/null && echo yes),) > > ifneq ($(CHECK_DT_BINDING)$(CHECK_DTBS),) > > $(error dtc needs libyaml for DT schema validation support. \ > > Install the necessary libyaml development package.) > > @@ -27,9 +27,9 @@ HOST_EXTRACFLAGS += -DNO_YAML > > else > > dtc-objs += yamltree.o > > # To include <yaml.h> installed in a non-default path > > -HOSTCFLAGS_yamltree.o := $(shell pkg-config --cflags yaml-0.1) > > +HOSTCFLAGS_yamltree.o := $(shell $(HOSTPKG_CONFIG) --cflags yaml-0.1) > > # To link libyaml installed in a non-default path > > -HOSTLDLIBS_dtc := $(shell pkg-config yaml-0.1 --libs) > > +HOSTLDLIBS_dtc := $(shell $(HOSTPKG_CONFIG) yaml-0.1 --libs) > > endif > > > > # Generated files need one more search path to include headers in source tree > > diff --git a/scripts/kconfig/gconf-cfg.sh b/scripts/kconfig/gconf-cfg.sh > > index 480ecd8b9f41..4da4e39dcb53 100755 > > --- a/scripts/kconfig/gconf-cfg.sh > > +++ b/scripts/kconfig/gconf-cfg.sh > > @@ -3,14 +3,14 @@ > > > > PKG="gtk+-2.0 gmodule-2.0 libglade-2.0" > > > > -if [ -z "$(command -v pkg-config)" ]; then > > +if [ -z "$(command -v ${HOSTPKG_CONFIG})" ]; then > > echo >&2 "*" > > echo >&2 "* 'make gconfig' requires 'pkg-config'. Please install it." > > echo >&2 "*" > > exit 1 > > fi > > > > -if ! pkg-config --exists $PKG; then > > +if ! ${HOSTPKG_CONFIG} --exists $PKG; then > > echo >&2 "*" > > echo >&2 "* Unable to find the GTK+ installation. Please make sure that" > > echo >&2 "* the GTK+ 2.0 development package is correctly installed." > > @@ -19,12 +19,12 @@ if ! pkg-config --exists $PKG; then > > exit 1 > > fi > > > > -if ! pkg-config --atleast-version=2.0.0 gtk+-2.0; then > > +if ! ${HOSTPKG_CONFIG} --atleast-version=2.0.0 gtk+-2.0; then > > echo >&2 "*" > > echo >&2 "* GTK+ is present but version >= 2.0.0 is required." > > echo >&2 "*" > > exit 1 > > fi > > > > -echo cflags=\"$(pkg-config --cflags $PKG)\" > > -echo libs=\"$(pkg-config --libs $PKG)\" > > +echo cflags=\"$(${HOSTPKG_CONFIG} --cflags $PKG)\" > > +echo libs=\"$(${HOSTPKG_CONFIG} --libs $PKG)\" > > diff --git a/scripts/kconfig/mconf-cfg.sh b/scripts/kconfig/mconf-cfg.sh > > index b520e407a8eb..05837ed07fbd 100755 > > --- a/scripts/kconfig/mconf-cfg.sh > > +++ b/scripts/kconfig/mconf-cfg.sh > > @@ -4,16 +4,16 @@ > > PKG="ncursesw" > > PKG2="ncurses" > > > > -if [ -n "$(command -v pkg-config)" ]; then > > - if pkg-config --exists $PKG; then > > - echo cflags=\"$(pkg-config --cflags $PKG)\" > > - echo libs=\"$(pkg-config --libs $PKG)\" > > +if [ -n "$(command -v ${HOSTPKG_CONFIG})" ]; then > > + if ${HOSTPKG_CONFIG} --exists $PKG; then > > + echo cflags=\"$(${HOSTPKG_CONFIG} --cflags $PKG)\" > > + echo libs=\"$(${HOSTPKG_CONFIG} --libs $PKG)\" > > exit 0 > > fi > > > > - if pkg-config --exists $PKG2; then > > - echo cflags=\"$(pkg-config --cflags $PKG2)\" > > - echo libs=\"$(pkg-config --libs $PKG2)\" > > + if ${HOSTPKG_CONFIG} --exists $PKG2; then > > + echo cflags=\"$(${HOSTPKG_CONFIG} --cflags $PKG2)\" > > + echo libs=\"$(${HOSTPKG_CONFIG} --libs $PKG2)\" > > exit 0 > > fi > > fi > > diff --git a/scripts/kconfig/nconf-cfg.sh b/scripts/kconfig/nconf-cfg.sh > > index c212255070c0..e8d8f12d93ac 100755 > > --- a/scripts/kconfig/nconf-cfg.sh > > +++ b/scripts/kconfig/nconf-cfg.sh > > @@ -4,16 +4,16 @@ > > PKG="ncursesw menuw panelw" > > PKG2="ncurses menu panel" > > > > -if [ -n "$(command -v pkg-config)" ]; then > > - if pkg-config --exists $PKG; then > > - echo cflags=\"$(pkg-config --cflags $PKG)\" > > - echo libs=\"$(pkg-config --libs $PKG)\" > > +if [ -n "$(command -v ${HOSTPKG_CONFIG})" ]; then > > + if ${HOSTPKG_CONFIG} --exists $PKG; then > > + echo cflags=\"$(${HOSTPKG_CONFIG} --cflags $PKG)\" > > + echo libs=\"$(${HOSTPKG_CONFIG} --libs $PKG)\" > > exit 0 > > fi > > > > - if pkg-config --exists $PKG2; then > > - echo cflags=\"$(pkg-config --cflags $PKG2)\" > > - echo libs=\"$(pkg-config --libs $PKG2)\" > > + if ${HOSTPKG_CONFIG} --exists $PKG2; then > > + echo cflags=\"$(${HOSTPKG_CONFIG} --cflags $PKG2)\" > > + echo libs=\"$(${HOSTPKG_CONFIG} --libs $PKG2)\" > > exit 0 > > fi > > fi > > diff --git a/scripts/kconfig/qconf-cfg.sh b/scripts/kconfig/qconf-cfg.sh > > index fa564cd795b7..9b695e5cd9b3 100755 > > --- a/scripts/kconfig/qconf-cfg.sh > > +++ b/scripts/kconfig/qconf-cfg.sh > > @@ -3,22 +3,22 @@ > > > > PKG="Qt5Core Qt5Gui Qt5Widgets" > > > > -if [ -z "$(command -v pkg-config)" ]; then > > +if [ -z "$(command -v ${HOSTPKG_CONFIG})" ]; then > > echo >&2 "*" > > - echo >&2 "* 'make xconfig' requires 'pkg-config'. Please install it." > > + echo >&2 "* 'make xconfig' requires '${HOSTPKG_CONFIG}'. Please install it." > > echo >&2 "*" > > exit 1 > > fi > > > > -if pkg-config --exists $PKG; then > > - echo cflags=\"-std=c++11 -fPIC $(pkg-config --cflags $PKG)\" > > - echo libs=\"$(pkg-config --libs $PKG)\" > > - echo moc=\"$(pkg-config --variable=host_bins Qt5Core)/moc\" > > +if ${HOSTPKG_CONFIG} --exists $PKG; then > > + echo cflags=\"-std=c++11 -fPIC $(${HOSTPKG_CONFIG} --cflags $PKG)\" > > + echo libs=\"$(${HOSTPKG_CONFIG} --libs $PKG)\" > > + echo moc=\"$(${HOSTPKG_CONFIG} --variable=host_bins Qt5Core)/moc\" > > exit 0 > > fi > > > > echo >&2 "*" > > -echo >&2 "* Could not find Qt5 via pkg-config." > > +echo >&2 "* Could not find Qt5 via ${HOSTPKG_CONFIG}." > > echo >&2 "* Please install Qt5 and make sure it's in PKG_CONFIG_PATH" > > echo >&2 "*" > > exit 1 > > diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile > > index 92ce4fce7bc7..549acc5859e9 100644 > > --- a/tools/objtool/Makefile > > +++ b/tools/objtool/Makefile > > @@ -19,8 +19,8 @@ LIBSUBCMD = $(LIBSUBCMD_OUTPUT)libsubcmd.a > > OBJTOOL := $(OUTPUT)objtool > > OBJTOOL_IN := $(OBJTOOL)-in.o > > > > -LIBELF_FLAGS := $(shell pkg-config libelf --cflags 2>/dev/null) > > -LIBELF_LIBS := $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf) > > +LIBELF_FLAGS := $(shell $(HOSTPKG_CONFIG) libelf --cflags 2>/dev/null) > > +LIBELF_LIBS := $(shell $(HOSTPKG_CONFIG) libelf --libs 2>/dev/null || echo -lelf) > > > > all: $(OBJTOOL) > > > > -- > > 2.35.1.616.g0bdcbb4464-goog > > > > > -- > Thanks, > ~Nick Desaulniers
On Tue, Mar 8, 2022 at 7:50 AM Chun-Tse Shao <ctshao@google.com> 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 <ctshao@google.com> 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. 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. -- Best Regards Masahiro Yamada
On Tue, Mar 08, 2022 at 01:01:45PM +0900, Masahiro Yamada wrote: > On Tue, Mar 8, 2022 at 7:50 AM Chun-Tse Shao <ctshao@google.com> 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 <ctshao@google.com> 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. > > > 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. > > > > > > -- > Best Regards > > Masahiro Yamada Thanks Masahiro! Will wait for your suggestion. -CT
Tue, Mar 08, 2022 at 01:01:45PM +0900, Masahiro Yamada wrote: > On Tue, Mar 8, 2022 at 7:50 AM Chun-Tse Shao <ctshao@google.com> 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 <ctshao@google.com> 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. > > > > > > -- > Best Regards > > Masahiro Yamada
On Wed, Mar 16, 2022 at 11:51 AM Chun-Tse Shao <ctshao@google.com> 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 <ctshao@google.com> 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 <ctshao@google.com> 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). "HOSTPKG_CONFIG" looks unbalanced due to the underscore. Perhaps, "HOST_PKG_CONFIG" might be better? [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 [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
On Tue, Mar 22, 2022 at 12:44 AM Masahiro Yamada <masahiroy@kernel.org> wrote: > > On Wed, Mar 16, 2022 at 11:51 AM Chun-Tse Shao <ctshao@google.com> 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 <ctshao@google.com> 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 <ctshao@google.com> 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. > > > > > [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`...) > > > > > > [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).
On Tue, Mar 22, 2022 at 10:19:14AM -0700, Nick Desaulniers wrote: > On Tue, Mar 22, 2022 at 12:44 AM Masahiro Yamada <masahiroy@kernel.org> wrote: > > > > On Wed, Mar 16, 2022 at 11:51 AM Chun-Tse Shao <ctshao@google.com> 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 <ctshao@google.com> 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 <ctshao@google.com> 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
On Tue, Mar 22, 2022 at 1:21 PM Chun-Tse Shao <ctshao@google.com> 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 <masahiroy@kernel.org> wrote: > > > > > > On Wed, Mar 16, 2022 at 11:51 AM Chun-Tse Shao <ctshao@google.com> 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 <ctshao@google.com> 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 <ctshao@google.com> 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
On Fri, Apr 1, 2022 at 6:58 AM Chun-Tse Shao <ctshao@google.com> wrote: > > On Tue, Mar 22, 2022 at 1:21 PM Chun-Tse Shao <ctshao@google.com> 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 <masahiroy@kernel.org> wrote: > > > > > > > > On Wed, Mar 16, 2022 at 11:51 AM Chun-Tse Shao <ctshao@google.com> 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 <ctshao@google.com> 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 <ctshao@google.com> 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.
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 <ctshao@google.com> wrote: > > > > On Tue, Mar 22, 2022 at 1:21 PM Chun-Tse Shao <ctshao@google.com> 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 <masahiroy@kernel.org> wrote: > > > > > > > > > > On Wed, Mar 16, 2022 at 11:51 AM Chun-Tse Shao <ctshao@google.com> 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 <ctshao@google.com> 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 <ctshao@google.com> 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/20220401231801.1532486-1-ctshao@google.com/ Just wondering if I should also do the same change for the pkg-config in comment in kconfig shell scripts? Thanks, CT
diff --git a/Makefile b/Makefile index daeb5c88b50b..f6c5bef7e141 100644 --- a/Makefile +++ b/Makefile @@ -430,6 +430,7 @@ else HOSTCC = gcc HOSTCXX = g++ endif +HOSTPKG_CONFIG = pkg-config export KBUILD_USERCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes \ -O2 -fomit-frame-pointer -std=gnu89 @@ -525,7 +526,7 @@ KBUILD_LDFLAGS_MODULE := KBUILD_LDFLAGS := CLANG_FLAGS := -export ARCH SRCARCH CONFIG_SHELL BASH HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE LD CC +export ARCH SRCARCH CONFIG_SHELL BASH HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE LD CC HOSTPKG_CONFIG export CPP AR NM STRIP OBJCOPY OBJDUMP READELF PAHOLE RESOLVE_BTFIDS LEX YACC AWK INSTALLKERNEL export PERL PYTHON3 CHECK CHECKFLAGS MAKE UTS_MACHINE HOSTCXX export KGZIP KBZIP2 KLZOP LZMA LZ4 XZ ZSTD diff --git a/certs/Makefile b/certs/Makefile index 3ea7fe60823f..fa540d14ef2d 100644 --- a/certs/Makefile +++ b/certs/Makefile @@ -89,5 +89,5 @@ targets += x509_revocation_list hostprogs := extract-cert -HOSTCFLAGS_extract-cert.o = $(shell pkg-config --cflags libcrypto 2> /dev/null) -HOSTLDLIBS_extract-cert = $(shell pkg-config --libs libcrypto 2> /dev/null || echo -lcrypto) +HOSTCFLAGS_extract-cert.o = $(shell $(HOSTPKG_CONFIG) --cflags libcrypto 2> /dev/null) +HOSTLDLIBS_extract-cert = $(shell $(HOSTPKG_CONFIG) --libs libcrypto 2> /dev/null || echo -lcrypto) diff --git a/scripts/Makefile b/scripts/Makefile index ce5aa9030b74..f084f08ed176 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -14,8 +14,8 @@ hostprogs-always-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert HOSTCFLAGS_sorttable.o = -I$(srctree)/tools/include HOSTLDLIBS_sorttable = -lpthread HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include -HOSTCFLAGS_sign-file.o = $(shell pkg-config --cflags libcrypto 2> /dev/null) -HOSTLDLIBS_sign-file = $(shell pkg-config --libs libcrypto 2> /dev/null || echo -lcrypto) +HOSTCFLAGS_sign-file.o = $(shell $(HOSTPKG_CONFIG) --cflags libcrypto 2> /dev/null) +HOSTLDLIBS_sign-file = $(shell $(HOSTPKG_CONFIG) --libs libcrypto 2> /dev/null || echo -lcrypto) ifdef CONFIG_UNWINDER_ORC ifeq ($(ARCH),x86_64) diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile index 95aaf7431bff..743fc08827ea 100644 --- a/scripts/dtc/Makefile +++ b/scripts/dtc/Makefile @@ -18,7 +18,7 @@ fdtoverlay-objs := $(libfdt) fdtoverlay.o util.o # Source files need to get at the userspace version of libfdt_env.h to compile HOST_EXTRACFLAGS += -I $(srctree)/$(src)/libfdt -ifeq ($(shell pkg-config --exists yaml-0.1 2>/dev/null && echo yes),) +ifeq ($(shell $(HOSTPKG_CONFIG) --exists yaml-0.1 2>/dev/null && echo yes),) ifneq ($(CHECK_DT_BINDING)$(CHECK_DTBS),) $(error dtc needs libyaml for DT schema validation support. \ Install the necessary libyaml development package.) @@ -27,9 +27,9 @@ HOST_EXTRACFLAGS += -DNO_YAML else dtc-objs += yamltree.o # To include <yaml.h> installed in a non-default path -HOSTCFLAGS_yamltree.o := $(shell pkg-config --cflags yaml-0.1) +HOSTCFLAGS_yamltree.o := $(shell $(HOSTPKG_CONFIG) --cflags yaml-0.1) # To link libyaml installed in a non-default path -HOSTLDLIBS_dtc := $(shell pkg-config yaml-0.1 --libs) +HOSTLDLIBS_dtc := $(shell $(HOSTPKG_CONFIG) yaml-0.1 --libs) endif # Generated files need one more search path to include headers in source tree diff --git a/scripts/kconfig/gconf-cfg.sh b/scripts/kconfig/gconf-cfg.sh index 480ecd8b9f41..4da4e39dcb53 100755 --- a/scripts/kconfig/gconf-cfg.sh +++ b/scripts/kconfig/gconf-cfg.sh @@ -3,14 +3,14 @@ PKG="gtk+-2.0 gmodule-2.0 libglade-2.0" -if [ -z "$(command -v pkg-config)" ]; then +if [ -z "$(command -v ${HOSTPKG_CONFIG})" ]; then echo >&2 "*" echo >&2 "* 'make gconfig' requires 'pkg-config'. Please install it." echo >&2 "*" exit 1 fi -if ! pkg-config --exists $PKG; then +if ! ${HOSTPKG_CONFIG} --exists $PKG; then echo >&2 "*" echo >&2 "* Unable to find the GTK+ installation. Please make sure that" echo >&2 "* the GTK+ 2.0 development package is correctly installed." @@ -19,12 +19,12 @@ if ! pkg-config --exists $PKG; then exit 1 fi -if ! pkg-config --atleast-version=2.0.0 gtk+-2.0; then +if ! ${HOSTPKG_CONFIG} --atleast-version=2.0.0 gtk+-2.0; then echo >&2 "*" echo >&2 "* GTK+ is present but version >= 2.0.0 is required." echo >&2 "*" exit 1 fi -echo cflags=\"$(pkg-config --cflags $PKG)\" -echo libs=\"$(pkg-config --libs $PKG)\" +echo cflags=\"$(${HOSTPKG_CONFIG} --cflags $PKG)\" +echo libs=\"$(${HOSTPKG_CONFIG} --libs $PKG)\" diff --git a/scripts/kconfig/mconf-cfg.sh b/scripts/kconfig/mconf-cfg.sh index b520e407a8eb..05837ed07fbd 100755 --- a/scripts/kconfig/mconf-cfg.sh +++ b/scripts/kconfig/mconf-cfg.sh @@ -4,16 +4,16 @@ PKG="ncursesw" PKG2="ncurses" -if [ -n "$(command -v pkg-config)" ]; then - if pkg-config --exists $PKG; then - echo cflags=\"$(pkg-config --cflags $PKG)\" - echo libs=\"$(pkg-config --libs $PKG)\" +if [ -n "$(command -v ${HOSTPKG_CONFIG})" ]; then + if ${HOSTPKG_CONFIG} --exists $PKG; then + echo cflags=\"$(${HOSTPKG_CONFIG} --cflags $PKG)\" + echo libs=\"$(${HOSTPKG_CONFIG} --libs $PKG)\" exit 0 fi - if pkg-config --exists $PKG2; then - echo cflags=\"$(pkg-config --cflags $PKG2)\" - echo libs=\"$(pkg-config --libs $PKG2)\" + if ${HOSTPKG_CONFIG} --exists $PKG2; then + echo cflags=\"$(${HOSTPKG_CONFIG} --cflags $PKG2)\" + echo libs=\"$(${HOSTPKG_CONFIG} --libs $PKG2)\" exit 0 fi fi diff --git a/scripts/kconfig/nconf-cfg.sh b/scripts/kconfig/nconf-cfg.sh index c212255070c0..e8d8f12d93ac 100755 --- a/scripts/kconfig/nconf-cfg.sh +++ b/scripts/kconfig/nconf-cfg.sh @@ -4,16 +4,16 @@ PKG="ncursesw menuw panelw" PKG2="ncurses menu panel" -if [ -n "$(command -v pkg-config)" ]; then - if pkg-config --exists $PKG; then - echo cflags=\"$(pkg-config --cflags $PKG)\" - echo libs=\"$(pkg-config --libs $PKG)\" +if [ -n "$(command -v ${HOSTPKG_CONFIG})" ]; then + if ${HOSTPKG_CONFIG} --exists $PKG; then + echo cflags=\"$(${HOSTPKG_CONFIG} --cflags $PKG)\" + echo libs=\"$(${HOSTPKG_CONFIG} --libs $PKG)\" exit 0 fi - if pkg-config --exists $PKG2; then - echo cflags=\"$(pkg-config --cflags $PKG2)\" - echo libs=\"$(pkg-config --libs $PKG2)\" + if ${HOSTPKG_CONFIG} --exists $PKG2; then + echo cflags=\"$(${HOSTPKG_CONFIG} --cflags $PKG2)\" + echo libs=\"$(${HOSTPKG_CONFIG} --libs $PKG2)\" exit 0 fi fi diff --git a/scripts/kconfig/qconf-cfg.sh b/scripts/kconfig/qconf-cfg.sh index fa564cd795b7..9b695e5cd9b3 100755 --- a/scripts/kconfig/qconf-cfg.sh +++ b/scripts/kconfig/qconf-cfg.sh @@ -3,22 +3,22 @@ PKG="Qt5Core Qt5Gui Qt5Widgets" -if [ -z "$(command -v pkg-config)" ]; then +if [ -z "$(command -v ${HOSTPKG_CONFIG})" ]; then echo >&2 "*" - echo >&2 "* 'make xconfig' requires 'pkg-config'. Please install it." + echo >&2 "* 'make xconfig' requires '${HOSTPKG_CONFIG}'. Please install it." echo >&2 "*" exit 1 fi -if pkg-config --exists $PKG; then - echo cflags=\"-std=c++11 -fPIC $(pkg-config --cflags $PKG)\" - echo libs=\"$(pkg-config --libs $PKG)\" - echo moc=\"$(pkg-config --variable=host_bins Qt5Core)/moc\" +if ${HOSTPKG_CONFIG} --exists $PKG; then + echo cflags=\"-std=c++11 -fPIC $(${HOSTPKG_CONFIG} --cflags $PKG)\" + echo libs=\"$(${HOSTPKG_CONFIG} --libs $PKG)\" + echo moc=\"$(${HOSTPKG_CONFIG} --variable=host_bins Qt5Core)/moc\" exit 0 fi echo >&2 "*" -echo >&2 "* Could not find Qt5 via pkg-config." +echo >&2 "* Could not find Qt5 via ${HOSTPKG_CONFIG}." echo >&2 "* Please install Qt5 and make sure it's in PKG_CONFIG_PATH" echo >&2 "*" exit 1 diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile index 92ce4fce7bc7..549acc5859e9 100644 --- a/tools/objtool/Makefile +++ b/tools/objtool/Makefile @@ -19,8 +19,8 @@ LIBSUBCMD = $(LIBSUBCMD_OUTPUT)libsubcmd.a OBJTOOL := $(OUTPUT)objtool OBJTOOL_IN := $(OBJTOOL)-in.o -LIBELF_FLAGS := $(shell pkg-config libelf --cflags 2>/dev/null) -LIBELF_LIBS := $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf) +LIBELF_FLAGS := $(shell $(HOSTPKG_CONFIG) libelf --cflags 2>/dev/null) +LIBELF_LIBS := $(shell $(HOSTPKG_CONFIG) libelf --libs 2>/dev/null || echo -lelf) all: $(OBJTOOL)
Add HOSTPKG_CONFIG to allow tooling that builds the kernel to override what pkg-config and parameters are used. Signed-off-by: Chun-Tse Shao <ctshao@google.com> --- Changes from v3: https://lore.kernel.org/all/20220304041449.939308-1-ctshao@google.com - Dereference variables using {} instead of () in shell scripts - Tested with make allmodconfig Changes from v2: https://lore.kernel.org/all/20220302193638.11034-1-ctshao@google.com/ - Fix more open coded instance of pkg-config in scripts and certs - Tested with make allmodconfig Changes from v1: https://lore.kernel.org/all/20220301230629.1892828-1-ctshao@google.com/ - Make the commit message more clearer. --- Makefile | 3 ++- certs/Makefile | 4 ++-- scripts/Makefile | 4 ++-- scripts/dtc/Makefile | 6 +++--- scripts/kconfig/gconf-cfg.sh | 10 +++++----- scripts/kconfig/mconf-cfg.sh | 14 +++++++------- scripts/kconfig/nconf-cfg.sh | 14 +++++++------- scripts/kconfig/qconf-cfg.sh | 14 +++++++------- tools/objtool/Makefile | 4 ++-- 9 files changed, 37 insertions(+), 36 deletions(-) -- 2.35.1.616.g0bdcbb4464-goog