On Fri, Dec 6, 2024 at 8:40 AM Hong, Yifan <elsk@xxxxxxxxxx> wrote: > > On Tue, Nov 12, 2024 at 10:45 AM Miguel Ojeda <ojeda@xxxxxxxxxx> wrote: > > > > From: HONG Yifan <elsk@xxxxxxxxxx> > > > > These are flags to be passed when linking proc macros for the Rust > > toolchain. If unset, it defaults to $(KBUILD_HOSTLDFLAGS). > > > > This is needed because the list of flags to link hostprogs is not > > necessarily the same as the list of flags used to link libmacros.so. > > When we build proc macros, we need the latter, not the former (e.g. when > > using a Rust compiler binary linked to a different C library than host > > programs). > > > > To distinguish between the two, introduce this new variable to stand > > out from KBUILD_HOSTLDFLAGS used to link other host progs. > > > > Signed-off-by: HONG Yifan <elsk@xxxxxxxxxx> > > Link: https://lore.kernel.org/r/20241017210430.2401398-2-elsk@xxxxxxxxxx > > [ v3: > > > > - `export`ed the variable. Otherwise it would not be visible in > > `rust/Makefile`. > > > > - Removed "additional" from the documentation and commit message, > > since this actually replaces the other flags, unlike other cases. > > > > - Added example of use case to documentation and commit message. > > Thanks Alice for the details on what Google needs! > > > > - Instead of `HOSTLDFLAGS`, used `KBUILD_HOSTLDFLAGS` as the fallback > > to preserve the previous behavior as much as possible, as discussed > > with Alice/Yifan. Thus moved the variable down too (currently we > > do not modify `KBUILD_HOSTLDFLAGS` elsewhere) and avoided > > mentioning `HOSTLDFLAGS` directly in the documentation. > > > > - Fixed documentation header formatting. > > > > - Reworded slightly. > > > > - Miguel ] > > Signed-off-by: Miguel Ojeda <ojeda@xxxxxxxxxx> > > --- > > Masahiro: if Kbuild wants to pick this up, that is great. Otherwise, I am happy > > picking this up early next cycle, if you give an `Acked-by` since this is > > changing the interface for Kbuild users given we are introducing a new > > environment variable. Thanks! > > > > Note that the `or` means if the string is empty, we will use the default rather > > than nothing. I didn't change that from Yifan's version, but maybe we want to do > > otherwise. Users can still provide e.g. an empty space to avoid any flag. > > I am not sure if I understand the implications here. > https://www.gnu.org/software/make/manual/html_node/Conditional-Functions.html > says: > > The or function provides a “short-circuiting” OR operation. Each > argument is expanded, in order. If an argument expands to a non-empty > string the processing stops and the result of the expansion is that > string. If, after all arguments are expanded, all of them are false > (empty), then the result of the expansion is the empty string. > > I am assuming that this means: > - If PROCMACROLDFLAGS is not empty, KBUILD_PROCMACROLDFLAGS evaluates > to PROCMACROLDFLAGS > - Otherwise if KBUILD_HOSTLDFLAGS is not empty, > KBUILD_PROCMACROLDFLAGS evaluates to KBUILD_HOSTLDFLAGS > - Otherwise KBUILD_PROCMACROLDFLAGS is set to empty. I think your understanding is correct. $(or A,B) works like $(if A,A,B) Commit 5c8166419acf shorten the code. > What do you mean by "use the default"? "use the default" means, "use $(KBUILD_HOSTLDFLAGS)" -- Best Regards Masahiro Yamada
