NACK: [SRU][M][PATCH 1/1] UBUNTU: [Packaging] define Rust flags only with Rust-enabled kernels

[Andrea Righi]

On Tue, Sep 26, 2023 at 02:16:17PM +0200, Juerg Haefliger wrote:
> On Tue, 26 Sep 2023 12:52:25 +0200
> Andrea Righi <andrea.righi at canonical.com> wrote:
> 
> > On Tue, Sep 26, 2023 at 11:27:43AM +0100, Dimitri John Ledkov wrote:
> > > On Tue, 26 Sept 2023 at 09:32, Andrea Righi <andrea.righi at canonical.com> wrote:  
> > > >
> > > > To enable Rust support in the kernel we need to pass special build
> > > > flags, that are used to select the proper Rust toolchain version and
> > > > dependent components.
> > > >
> > > > These flags are passed also to the scripts called during the
> > > > updateconfigs step and the build, such as 'kernelconfig', using the
> > > > $(kmake) variable.
> > > >
> > > > However, $(kmake) can also contain cross-compiler variables that may
> > > > potentially affect the config or the build in certain architectures.  
> > > 
> > > Not potentially, but intentionally.
> > > 
> > > Because sometimes we use different gcc for different arch (i.e. gcc-11
> > > for armhf, and gcc-12 for arm64 build), and we must use full kmake for
> > > generating the configs that should be the same as the one that will be
> > > used for build.  
> > 
> > This is a valid point, I think there's still value to isolate the Rust
> > options in a separate variable
> 
> Why a separate variable? Isn't it enough to simply add them to kmake for
> rust-enabled kernels?

The amount of env variables can change between a kernel version and
another (we may need to foce a specific clang/libclang, or host rustc,
or potentially other dependencies required by Rust), that's why I'd
prefer to isolate these extra options rather than mixing them into kmake
directly.

More in general, I'd really love if we could evaluate all these options
at build time, instead of config time... There is this trend now in the
kernel to add scripts used by Kconfig to probe system tools and libs at
config time and set the config options accordingly. That is quite bad
for us, because our config phase is decoupled from the build phase and
often the config environment is different than the build environment
(especially with devel kernels).

I think it would be much better for us to have the possibility (special
option?) to say "enable whatever I need, without checking what's
installed in my system" and then if something is missing at build time,
simply let the build fail.

-Andrea