On Fri, Dec 15, 2023 at 8:27 PM Miguel Ojeda <miguel.ojeda.sandonis@xxxxxxxxx> wrote: > > On Fri, Dec 15, 2023 at 8:38 AM David Gow <davidgow@xxxxxxxxxx> wrote: > > > > Would having similar targets for bindgen help? What about having this > > install rust-src? Updating / installing those required a lot more > > looking up of documentation (and then adding --force), so it'd be nice > > if there were some way to do a similar override or make target. > > Which docs did you need to check? i.e. we have the commands for those > steps in the Quick Start guide. I think you may be referring to the > case when switching between LTS and mainline, due to the `bindgen-cli` > vs. `bindgen` name change that the tool did (since that is where > `--force` is required, not for normal upgrading or downgrading). That > is definitely a bit painful :-( At least `cargo` mentions the need for > `--force` in that case. Or are you referring to something else? > > I considered having a `rustupsetup` target (or script) instead that > does everything (with a `BUILDONLY=1` option or similar, given some > dependencies are not strictly needed for building), since having all > this "switching logic" is useful, but then: > > - I am not sure we should "hide" the details of the setup too much: > I thought `rustupoverride` would be OK-ish because the output > directory is needed (so it is justified) and the command is > straightforward, but the others do not "need" that information. > > - If we include `bindgen` there, it wouldn't be `rustup`-only > anymore, so perhaps we would need another name like `rustsetup`. But > that may mislead others (e.g. those looking at the Make help), because > it is just one way of setting things up and it is not required. > Perhaps this can be alleviated by not including it in the `make help`, > so that everybody comes from the Quick Start guide and thus hopefully > they have read the document at least diagonally :) > > - Given there are different ways to set different sub-steps, and the > fact that we don't have such a script for C does not have (please > correct me if I am wrong -- I am aware of Thorsten's recent guide, > which covers `apt` etc., but that is a Quick Start-like approach > rather than automated script), I am not sure it would be welcome as a > Make target (but perhaps it would be fine as a script?). Masahiro may > have some guidelines here. 'make rustupoverride' potentially requires internet connection if the required rustc version is not yet installed on the system. Even if it is already installed, it changes ~/.rustup/settings.toml. If I do rustupoverride per-directory, $ make O=~/kernel/build0 rustupoverride $ make O=~/kernel/build1 rustupoverride $ make O=~/kernel/build2 rustupoverride it would accumulate the overrides entries in ~/.rustup/settings.toml Rather, I will manually do this one time for the parent directory: $ rustup override set --path=/~kernel $(scripts/min-tool-version.sh rustc) and use ~/kernel/build0, ~/kernel/build1, ~/kernel/build2 as output directories. In principle, Kbuild does not require internet connection, or proactively change the system setting. If you want to provide a way for automated settings, you can do it in a script you maintain. > - In the future we may have to change how the setup works or add > steps, i.e. it is not 100% settled. Thus I am concerned about adding > complex Make targets that users may start to depend on (i.e. with > particular/complex semantics), vs. just having docs that are manual. > For `rustupoverride`, it thought it could be OK-ish because it is just > a single command and unlikely that it will change (and if we stop > using it, we can make it empty with a warning and then remove it > eventually; while it gets harder for more complex ones). > > What do you think? > > Cheers, > Miguel -- Best Regards Masahiro Yamada
