linux-kernel - Re: [PATCH v2 1/1] rust: add `rustcheck` make target for check-only builds

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250923064720.0b2ea467@nimda>
Date: Tue, 23 Sep 2025 06:47:20 +0300
From: Onur Özkan <work@...rozkan.dev>
To: Nicolas Schier <nicolas.schier@...ux.dev>
Cc: rust-for-linux@...r.kernel.org, ojeda@...nel.org, nathan@...nel.org,
 masahiroy@...nel.org, aliceryhl@...gle.com,
 thomas.weissschuh@...utronix.de, tamird@...il.com,
 linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
 alex.gaynor@...il.com, boqun.feng@...il.com, gary@...yguo.net,
 bjorn3_gh@...tonmail.com, lossin@...nel.org, a.hindborg@...nel.org,
 tmgross@...ch.edu, dakr@...nel.org
Subject: Re: [PATCH v2 1/1] rust: add `rustcheck` make target for check-only
 builds

On Mon, 22 Sep 2025 08:02:36 +0200
Nicolas Schier <nicolas.schier@...ux.dev> wrote:

> On Mon, Sep 15, 2025 at 02:53:11PM +0300, Onur Özkan wrote:
> > Adds a new `rustcheck` make target to run a check-only build
> > similar to `cargo check`. This allows us to verify that the Rust
> > sources can build without building/linking final artifacts,
> > which speeds up the iteration (a lot) during development.
> > 
> > The target also supports the CLIPPY flag (e.g., `make LLVM=1
> > rustcheck CLIPPY=1) to run Clippy in a faster way.
> > 
> > Also, unlike `make LLVM=1`, it doesn't compile large amounts of C
> > code (on a fresh checkout) when the goal is only to check that
> > Rust builds are not broken after some changes.
> > 
> > Suggested-by: Benno Losin <lossin@...nel.org>
> > Link:
> > https://rust-for-linux.zulipchat.com/#narrow/channel/288089/topic/x/near/539103602
> > Signed-off-by: Onur Özkan <work@...rozkan.dev> ---
> >  Makefile      |  7 +++++
> >  rust/Makefile | 73
> > +++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files
> > changed, 80 insertions(+)
> > 
> > diff --git a/Makefile b/Makefile
> > index cf37b9407821..7812cdc72938 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1716,6 +1716,8 @@ help:
> >  	@echo  '		    is formatted, printing a diff
> > otherwise.' @echo  '  rustdoc	  - Generate Rust
> > documentation' @echo  '		    (requires kernel
> > .config)'
> > +	@echo  '  rustcheck       - Check that the Rust code
> > builds'
> > +	@echo  '                    (requires kernel .config)'
> >  	@echo  '  rusttest        - Runs the Rust tests'
> >  	@echo  '                    (requires kernel .config;
> > downloads external repos)' @echo  '  rust-analyzer	  -
> > Generate rust-project.json rust-analyzer support file' @@ -1821,6
> > +1823,11 @@ PHONY += rustdoc rustdoc: prepare
> >  	$(Q)$(MAKE) $(build)=rust $@
> >  
> > +# Checking Rust sources.
> > +PHONY += rustcheck
> > +rustcheck: prepare0
> 
> Why do you let rustcheck depend on prepare0 instead of prepare?
> 

Because "prepare" does more job which isn't necessary (therefore waste
of time) for "rustcheck".

> > +	$(Q)$(MAKE) $(build)=rust $@
> > +
> >  # Testing target
> >  PHONY += rusttest
> >  rusttest: prepare
> > diff --git a/rust/Makefile b/rust/Makefile
> > index bfa915b0e588..b45878870207 100644
> > --- a/rust/Makefile
> > +++ b/rust/Makefile
> > @@ -265,6 +265,79 @@ rusttest-kernel: $(src)/kernel/lib.rs
> > rusttestlib-ffi rusttestlib-kernel \ rusttestlib-uapi
> > rusttestlib-pin_init FORCE +$(call if_changed,rustc_test)
> >  
> > +## Check-only compilation (similar to `cargo check`)
> > +quiet_cmd_rustc_check_library = $(RUSTC_OR_CLIPPY_QUIET) CHECK $<
> > +      cmd_rustc_check_library = \
> > +        OBJTREE=$(abspath $(objtree)) \
> 
> Have you tried this?
> 
>         OBJTREE=$(CURDIR) \
> 
> or
> 
>         OBJTREE=$(abs_output) \
> 
> I'd favor using one of these instead.
> 

I don't have a strong opinion on any of them. I followed the existing
approach from the other use cases used in the same file.

Regards,
Onur