Re: [PATCH v3] kbuild: rust: add PROCMACROLDFLAGS

[Hong, Yifan]

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