On Thu, Dec 5, 2024 at 5:28 PM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote: > > 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)" Thank you for confirming. I think this is my original intention. If PROCMACROLDFLAGS (a new API) is not set, the code should have the same behavior as before this patch, i.e. cmd_rustc_procmacro uses -Clink-args KBUILD_HOSTLDFLAGS. This minimizes surprises for existing users. > > > -- > Best Regards > Masahiro Yamada
