On Wed, Mar 16, 2022 at 11:51 AM Chun-Tse Shao <ctshao@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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
