On Fri, 15 Dec 2023 at 19:27, 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? Yeah, I only needed to check the Quick Start guide, but had to look at all three sections (rustc, rust-src, bindgen), which And yes, it looks like the bindgen/bindgen-cli name change was what was causing my issues. If that's only a one-off, then we should be fine. ( > 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. Yeah; I'm a bit conflicted here as well. A part of me thinks that, if we're adding make targets, doing them for everything would be more consistent, but it does add some 'unnecessary' targets, which is probably not worth it just to look nice. > - 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 :) Personally, I'd love a 'make rustsetup' or similar, but I do agree it could be misleading, particularly long-term. The real advantage to it is while we're depending on unstable things and changing versions regularly. I don't think the one-off setup is tricky (and the documentation is good), it's the need to upgrade regularly (and, for per-directory overrides, possibly on several different checkouts). Having a script to 'upgrade everything to the required version' would be really convenient. > - 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. > > - 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? Yeah, on reflection it's definitely not a good long-term solution, as ideally people will be able to just use whatever rustc version they have lying around (be it via rustup, or distro packages). Maybe what we need in the short term is an 'update-rust' script (possibly living in scripts/, possibly hosted elsewhere, like the rust-for-linux website), which just does all the steps from the Quick Start guide automatically? (Even if that's not a good solution overall, I'll probably throw one together myself just to keep my own systems up-to-date.) Still -- none of this is a blocker for this patch. Cheers, -- David
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
