Split Rust arguments into a new scripts/Makefile.rust#1026
Split Rust arguments into a new scripts/Makefile.rust#1026tgross35 wants to merge 1 commit intoRust-for-Linux:rust-nextfrom
scripts/Makefile.rust#1026Conversation
Currently, all Rust flags live in the top level 'Makefile'. This patch moves these flags to a new file at 'scripts/Makefile.rust' so that wanted adjustments to Rust's CLI configuration can be applied without touching the root 'Makefile'. This change is intended to reduce noise and the potential for merge conflicts. Making this change will simplify the goals of (1) adding additional lints over time, and (2) changing from specifying lint groups (e.g. 'correctness', 'perf') to naming individual lints for better version compatibility. These changes are space consuming (>100 lines) and may have a few adjustments per cycle, so extracting these arguments out of the shared 'Makefile' should be much less noisy for everyone. Signed-off-by: Trevor Gross <tmgross@umich.edu>
tgross35
force-pushed
the
split-rust-makefile
branch
from
15572e9 to
2687b74
Compare
|
I'm not sure how much splitting you were interested in @ojeda. This patch as-is currently just moves the flags, but I also experimented with moving almost everything Rust-related to this file (KBUILD_x and all the Rust-related targets), which could be cleaner overall. (side note - I wonder if it would be possible to have a |
|
I would only move the common flags to begin with and do so in the same patch series that adds the other lints/comments, because that is the motivation for this move, and keeps things simple. If we don't have a fair amount of comments/lints to add, it would be simpler to avoid the move altogether. Unless we want to go for an actual refactor, that is. It is true that we could move other flags and other bits, and that was half my intention for using the name |
|
Understood, I was thinking that it would be preferred to keep this top-level change separate from the other Rust-specific changes - but I will merge them back together. Thanks for the look! |
|
My pleasure! Thanks for working on this and taking a look at the different potential approaches, it is appreciated! |
2 participants
This follows the discussion at #1025