Re: [dpdk-stable] [PATCH 1/1] devtools: fix build test config inheritance from env

[Thomas Monjalon <thomas@monjalon.net>]

11/11/2020 12:13, Ferruh Yigit:
> On 11/11/2020 11:00 AM, Bruce Richardson wrote:
> > On Wed, Nov 11, 2020 at 11:37:41AM +0100, Thomas Monjalon wrote:
> >> 11/11/2020 10:18, Bruce Richardson:
> >>> On Tue, Nov 10, 2020 at 06:09:45PM +0000, Ferruh Yigit wrote:
> >>>> On 11/10/2020 5:55 PM, Thomas Monjalon wrote:
> >>>>> 10/11/2020 18:18, Ferruh Yigit:
> >>>>>> On 11/9/2020 9:00 PM, Thomas Monjalon wrote:
> >>>>>>> PKG_CONFIG_PATH is specific to each target, so it must be empty
> >>>>>>> before configuring each build from the file according to DPDK_TARGET.
> >>>>>>> Inheriting a default PKG_CONFIG_PATH for all targets does not make sense
> >>>>>>> and is prone to confusion.
> >>>>> [...]
> >>>>>> In same run both 64bit and 32bit builds are done,
> >>>>>
> >>>>> Multiple targets can be built yes.
> >>>>>
> >>>>>> At least for my environment,
> >>>>>> for 64bit, PKG_CONFIG_PATH should be '/usr/local/lib64/pkgconfig/'
> >>>>>> for 32bit, PKG_CONFIG_PATH should be '/usr/lib/pkgconfig/'
> >>>>>
> >>>>> Not sure you need to set these values in PKG_CONFIG_PATH.
> >>>>> At least /usr/lib/pkgconfig/ is already set in PKG_CONFIG_LIBDIR.
> >>>>>
> >>>>> Let me rephrase the man page of pkg-config:
> >>>>> PKG_CONFIG_LIBDIR is the primary paths list
> >>>>> PKG_CONFIG_PATH is the secondary paths list
> >>>>>
> >>>>>> What should I set in the config file to support both?
> >>>>>
> >>>>> The standard paths for your 64-bit machine should be built-in
> >>>>> in your pkg-config.
> >>>>> The standard path for 32-bit is already set automatically
> >>>>> in devtools/test-meson-builds.sh.
> >>>>> Only additional specific paths should be set in a config file.
> >>>>>
> >>>>> What is a config file? It is loaded by devtools/load-devel-config:
> >>>>> 	- /etc/dpdk/devel.config (system-wide)
> >>>>> 	- or ~/.config/dpdk/devel.config (user config)
> >>>>> 	- or .develconfig (project directory config)
> >>>>> Personally I set all my configs in ~/.config/dpdk/devel.config.
> >>>>> Note that the same file is used to configure multiple tools.
> >>>>>
> >>>>> For each build, some variables are reset the variable DPDK_TARGET is set,
> >>>>> and the config file is sourced.
> >>>>> The typical values of DPDK_TARGET are:
> >>>>> 	- i386-pc-linux-gnu
> >>>>> 	- x86_64-pc-linux-gnu
> >>>>> 	- x86_64-w64-mingw32
> >>>>> 	- aarch64-linux-gnu
> >>>>> 	- powerpc64le-linux-gcc
> >>>>>
> >>>>> TLDR, I assume you just want to set an additional 64-bit path,
> >>>>> so the config file should look like:
> >>>>>
> >>>>> if [ "$DPDK_TARGET" = x86_64-pc-linux-gnu ] ; then
> >>>>> 	export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib64/pkgconfig
> >>>>> fi
> >>>>>
> >>>>>
> >>>>
> >>>> Thanks for the clarification.
> >>>>
> >>>> Standard paths seems should be covered already in current script, which I
> >>>> was trying to do with "export PKG_CONFIG_PATH=$CUSTOM_PKG_CONFIG_PATH" line
> >>>> in my patch,
> >>>>
> >>>> I may be mixed 'PKG_CONFIG_LIBDIR' vs 'PKG_CONFIG_PATH' usage, let me check
> >>>> it in my environment.
> >>>>
> >>>
> >>> For just adding a new custom path for pkg-config using PKG_CONFIG_PATH. For
> >>> building anything other than a native 64-bit build you need to override
> >>> PKG_CONFIG_LIBDIR and clear PKG_CONFIG_PATH, otherwise the 64-bit packages
> >>> will be found from the standard paths if not found in a 32-bit one.
> >>
> >> Yes, this is what is done in this patch (clearing PKG_CONFIG_PATH).
> >> May I assume you are all OK with this patch now?
> >>
> > Yes, I previously acked it, I believe.
> > 
> 
> 'PKG_CONFIG_LIBDIR' seems replaces the pkgconfig defaults,
> 'PKG_CONFIG_PATH' adds paths to process *before* built-in ones.
> 
> With adjustment according above, all looks good to me.
> 
> What about unset the variable "uset PKG_CONFIG_PATH", to set it to empty to get 
> rid of the following line from logs:
> "Using 'PKG_CONFIG_PATH' from environment with value: ''"

Oh yes I didn't notice this message.
The reason why I didn't unset was to allow referencing empty variable
with shell option which forbids referencing unset ones: set -u.

Now I think it's better to unset.

> With or without about change,
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>