From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D932FC4332F for ; Fri, 1 Apr 2022 23:42:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353438AbiDAXom (ORCPT ); Fri, 1 Apr 2022 19:44:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55638 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236763AbiDAXok (ORCPT ); Fri, 1 Apr 2022 19:44:40 -0400 Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1506E1F161D for ; Fri, 1 Apr 2022 16:42:48 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id n18so3729257plg.5 for ; Fri, 01 Apr 2022 16:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=c1wlQXQD7j8UDoQIloz64lt6ox2JA7LYHav5SuNwpO0=; b=UJ6JPg0HgboOxHto5QxUkWcInf9E5qf0MLbfUhV7BLfoY52liL1QK7NllRJwdwk7rk cPF6jn0LSkRLLmQeEz0diq0yo35YaRyKLOSFKIDqcgRu0pf9smWhs4TZmZrLcCHvrETc E7Zw2NQ0HJRajG/FSDYtR+U7hEpgmQx7u3Yb+txujC0Eoa6Uo3XVAZ4LB9YkpXDYCguE s7pjeSW8U00QKaivQ3Zo9Jif0i7i0zo6mXsoElZG0gzKf5vyyBWEen9vGAKXEmjEYho0 tbbVqQUQyKqvls1fcKXL2y9aobSlUje1uB7VG5lFfyiNKPy9kyJP9i2uoJVdOiY/XimS Rxww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=c1wlQXQD7j8UDoQIloz64lt6ox2JA7LYHav5SuNwpO0=; b=H+1/lgm+T4csxXnwzDjz/qRXPT8ZMciWeQtZ4hCpEGyxyZM5OaOrCVxYG40qTMUGik ZswpCy5e+C+uS0kMMHIw1DA6sVMUOCG8+AboGss0MlIlajnDkMHQLp21kNuU5dWWHoXs ND7Q8TIWOxks/IJAzpuAY2Atzqgl31It+HtLvMNboeEd298M+7tiRTEPSYHOVHXJQHEZ a5+cBZ90u096sr3QgSKXRDzJGbX71dw99erEkuyn36lCXyKegjVcFRhcjUcwNOnFJL1F 4f4KSbXE2ev4vBvytPsaKerycD7EQDJc65zOPtpL2eWMduX81p7glkBUoOo0i5guhVG3 qGZg== X-Gm-Message-State: AOAM530rFY3kURM2gAHtxYFY4ybLoOmVG8zKyLsD/9yF78B65q6p7VTO X1PGt0XkJTe7Jss384KhixpmOA== X-Google-Smtp-Source: ABdhPJzNfMCJlJiC2ukKUraZckvngUpv0BXMwuWY2kZKzwd6kopUR5V6JnUJIPKxk/jlVxyap1owZw== X-Received: by 2002:a17:902:ce02:b0:153:bd65:5c0e with SMTP id k2-20020a170902ce0200b00153bd655c0emr12426812plg.160.1648856567070; Fri, 01 Apr 2022 16:42:47 -0700 (PDT) Received: from google.com (223.103.125.34.bc.googleusercontent.com. [34.125.103.223]) by smtp.gmail.com with ESMTPSA id g70-20020a636b49000000b003823dd39d41sm3259582pgc.64.2022.04.01.16.42.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Apr 2022 16:42:46 -0700 (PDT) Date: Fri, 1 Apr 2022 23:42:41 +0000 From: Chun-Tse Shao To: Masahiro Yamada Cc: Nick Desaulniers , Steven Rostedt , Nicolas Schier , Rob Herring , Michal Marek , David Howells , David Woodhouse , Frank Rowand , Josh Poimboeuf , Peter Zijlstra , Linux Kbuild mailing list , Linux Kernel Mailing List , keyrings@vger.kernel.org, DTML Subject: Re: [PATCH v4] config: Allow kernel installation packaging to override pkg-config Message-ID: References: <20220306223016.2239094-1-ctshao@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 wrote: > > > > On Tue, Mar 22, 2022 at 1:21 PM Chun-Tse Shao 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 wrote: > > > > > > > > > > On Wed, Mar 16, 2022 at 11:51 AM Chun-Tse Shao 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 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 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 -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