Message ID | e2b943eca92abebbf035447b3569f09a7176c770.1702366951.git.viresh.kumar@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6359:4293:b0:170:897c:21ad with SMTP id kp19csp2919437rwb; Mon, 11 Dec 2023 23:44:08 -0800 (PST) X-Google-Smtp-Source: AGHT+IHpGy2X300MvrZKcDgE/bjOBXPKCv7dP21pnlF1ZiFVTAQPWS5AoxucWdglIoR9gyf/OaQ2 X-Received: by 2002:a05:6e02:12c6:b0:35a:fad3:2b2a with SMTP id i6-20020a056e0212c600b0035afad32b2amr8892128ilm.12.1702367048215; Mon, 11 Dec 2023 23:44:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702367048; cv=none; d=google.com; s=arc-20160816; b=RkrEgWu7QNoDGEy1Y47UTQHZQ3iba4HsRnWKs4+RVRJDtQCJksl4L+7Xy6Ao4OukUi 2CYUjRldawZVshYIPReuP4rzqbnSLDEvBROcQZYA6rMIthhXVB/dr68CgPlDJv0U1rZl v0WvqZsPWklI+vpnwzER5E2/5CBaiIuDyHv+Pi5uapjuKBks3umAWpNa+nPOg06yWBzc VmS/UegXvNIAFRVew2802Sm+SfnnymQnETG7drMPKQbOvZJN0XrYXVnrFfDWURWENKeS NjOdcborsp2cGMEbdANzM8WvORh3Vlrfx74/ivazMISQxUKL+/SpSa4aCPCRTdhmnqvR HAvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=TOXKU7bsGbNdHwHYKjDdosOGqerCEfbXvQrWb4UvRVA=; fh=AWheenlwQKwAPagYmVafMJBzzjN+Z5vXHGrn/fU/DOg=; b=ZpTG7X/QleZiEkHU94rlKGnzC+L0Kfnieut+JgY+/PkU+95Dzk1b2rXutjU7cW5s3e vd9H+pP+8KGdnXBZpnVlmiuaSSVM+Ofsjnoep5V5Qx97MIDjA4366lEFZW3sL/JlLoW0 pmB983NRnchkld2/l1sMWxi4ehURupWolUoK4MChfpxeej12oRr9AVXOUCIifVQnLcci zG+geWbUethEFY6V/N+o1vuYokhhL3pURzyk7b9s+jnOO5SlP2bv31HoW+Cgz4IdXx4z M4jXuv95X5cVR4WJag+qHrhltYsCJBuJMSl7YGDjg3MDTQ9KiqryNLZCimcjxQnt2emv Tz+g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=LSo5XZFI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from lipwig.vger.email (lipwig.vger.email. [23.128.96.33]) by mx.google.com with ESMTPS id w17-20020a170902e89100b001cfb1dae607si7406012plg.146.2023.12.11.23.44.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Dec 2023 23:44:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=LSo5XZFI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id A3E8A809B9CC; Mon, 11 Dec 2023 23:44:05 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231210AbjLLHnw (ORCPT <rfc822;dexuan.linux@gmail.com> + 99 others); Tue, 12 Dec 2023 02:43:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40138 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230473AbjLLHnv (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 12 Dec 2023 02:43:51 -0500 Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 16D4CC2 for <linux-kernel@vger.kernel.org>; Mon, 11 Dec 2023 23:43:57 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id 46e09a7af769-6d9f9fbfd11so2250088a34.2 for <linux-kernel@vger.kernel.org>; Mon, 11 Dec 2023 23:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1702367036; x=1702971836; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=TOXKU7bsGbNdHwHYKjDdosOGqerCEfbXvQrWb4UvRVA=; b=LSo5XZFIc/VUGHNlD/o56Rk2QJkMRRxPmj/6S+vhtduOpSWVmESkYQ4SxUJ442BijS aSuqHfvmvWekqgxUN1RxOntxyQNV7MHgOUx5AVlyu8VmbtlvtxkGNscRUmymye7DG7lu G86q3j5QMnwUbO9MV7I1EnHQS5IHFOn3Iv63bw5Q8NC03KpdUZEZrUKDJkyyZoD6F0K5 S5Q1q8D93f0tCHC9EJbcwqOuilkiDujcQFsrelaGsfG0QkaA7GvSRpUu1Fp6jjfhIehN onRKLZ3gWOEJ2kDEIz+56bTUzkHnziQlx5EI7IXQA4zsdlhw9zjK3eAvexXyjTVme+Wm w+eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702367036; x=1702971836; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TOXKU7bsGbNdHwHYKjDdosOGqerCEfbXvQrWb4UvRVA=; b=J+gH1me8BjmvAzy7wTEz7ZxRtJfO2JxhvW6VMwr8E1UmJSW07kF7eFpz75frmTZJNi Fb5qf5XuyRstXo8YjbHqyhcHN+20FA3Pudbogn7+d10qePPb6bXTUChOPfG40xlPy8bt HMXU/ltEGbjg3IfgfSbdL/ag2TB7PLXVPPJ0jUIaPEjsqrhcurB8ciop0RUS0cG9aEZy EmYQy2IsGHbauE39CV0IkVZ3ITRr7MDQmTi8rNbTikGbdcjqMXBv1merr+JEimcDKDaL kSmSJjXWJpJHQk0ktUDyUptZZq9dqCv/N9mQu/F+J/r3b+B8IV9FuFdse+DR1OczOn4j wsaQ== X-Gm-Message-State: AOJu0YwmA/0UxC7QYke73GZs1VztTe619AAQ72slVyZQzfiRgXq4QsKa pfKLUoBsVZpi7A85ru0mqNOBWA== X-Received: by 2002:a05:6830:615:b0:6d9:f334:f886 with SMTP id w21-20020a056830061500b006d9f334f886mr5749871oti.18.1702367036432; Mon, 11 Dec 2023 23:43:56 -0800 (PST) Received: from localhost ([122.172.82.6]) by smtp.gmail.com with ESMTPSA id d12-20020a056a0010cc00b006ce61c9495fsm7470500pfu.206.2023.12.11.23.43.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Dec 2023 23:43:55 -0800 (PST) From: Viresh Kumar <viresh.kumar@linaro.org> To: Miguel Ojeda <ojeda@kernel.org>, Alex Gaynor <alex.gaynor@gmail.com>, Wedson Almeida Filho <wedsonaf@gmail.com>, Boqun Feng <boqun.feng@gmail.com>, Gary Guo <gary@garyguo.net>, =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= <bjorn3_gh@protonmail.com>, Benno Lossin <benno.lossin@proton.me>, Andreas Hindborg <a.hindborg@samsung.com>, Alice Ryhl <aliceryhl@google.com>, Jonathan Corbet <corbet@lwn.net> Cc: Viresh Kumar <viresh.kumar@linaro.org>, Vincent Guittot <vincent.guittot@linaro.org>, rust-for-linux@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH V2] docs: rust: Clarify that 'rustup override' applies to build directory Date: Tue, 12 Dec 2023 13:13:48 +0530 Message-Id: <e2b943eca92abebbf035447b3569f09a7176c770.1702366951.git.viresh.kumar@linaro.org> X-Mailer: git-send-email 2.31.1.272.g89b43f80a514 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Mon, 11 Dec 2023 23:44:05 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785061229473127537 X-GMAIL-MSGID: 1785061229473127537 |
Series |
[V2] docs: rust: Clarify that 'rustup override' applies to build directory
|
|
Commit Message
Viresh Kumar
Dec. 12, 2023, 7:43 a.m. UTC
Rustup override is required to be set for the build directory and not
necessarily the kernel source tree (unless the build directory is its
subdir).
Clarify the same in quick-start guide.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
V2:
- Made few changes based on review comments.
Documentation/rust/quick-start.rst | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
Comments
On Tue, Dec 12, 2023 at 8:43 AM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > Rustup override is required to be set for the build directory and not > necessarily the kernel source tree (unless the build directory is its > subdir). > > Clarify the same in quick-start guide. > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com>
On 12/12/23 08:43, Viresh Kumar wrote: > Rustup override is required to be set for the build directory and not > necessarily the kernel source tree (unless the build directory is its > subdir). > > Clarify the same in quick-start guide. > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Benno Lossin <benno.lossin@proton.me>
On 12/12/2023 07:43, Viresh Kumar wrote: > Rustup override is required to be set for the build directory and not > necessarily the kernel source tree (unless the build directory is its > subdir). > > Clarify the same in quick-start guide. > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> > --- > V2: > - Made few changes based on review comments. > > Documentation/rust/quick-start.rst | 12 ++++++++---- > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst > index f382914f4191..7ea931f74e09 100644 > --- a/Documentation/rust/quick-start.rst > +++ b/Documentation/rust/quick-start.rst > @@ -33,14 +33,18 @@ A particular version of the Rust compiler is required. Newer versions may or > may not work because, for the moment, the kernel depends on some unstable > Rust features. > > -If ``rustup`` is being used, enter the checked out source code directory > -and run:: > +If ``rustup`` is being used, enter the kernel build directory (or use > +`--path=<build-dir>` argument to the `set` sub-command) and run:: > > rustup override set $(scripts/min-tool-version.sh rustc) > `scripts/min-tool-version.sh` won't exist within the build dir if the option the user takes is "enter the kernel build directory", right? It only works if they use the `--path` argument in the `rustup override set` option. I gave this a spin and works as expected, just thought I would mention this given how users sometimes simply copy/paste and this may be confusing. Tiago.
On Thu, Dec 14, 2023 at 2:26 PM Tiago Lam <tiagolam@gmail.com> wrote: > > `scripts/min-tool-version.sh` won't exist within the build dir if the > option the user takes is "enter the kernel build directory", right? It > only works if they use the `--path` argument in the `rustup override > set` option. Yeah, the script is in the source tree, and the path is the build tree. Giving a single one-liner with `--path <builddir>` and `<srctree>/scripts...` would be simplest in the sense that it would allow us to remove even the "enter ..." part too. But then the command cannot be copy-pasted and it is likely harder for newcomers that may not be using `O=`. Something like v1 but a bit simpler, e.g. keeping things as they are, but with just a sentence after the command like "If you are building the kernel with `O=`, i.e. specifying an output directory, then you should append `--path <builddir>`." could work. Or we could just provide a `rustupoverride` Make target to do this for us [1], since we have all the information needed and would be copy-pasteable by everybody. I can send it as a non-mangled patch and then Viresh can redo this one on top using it. Cheers, Miguel [1] diff --git a/Makefile b/Makefile index 70fc4c11dfc0..7fe82dd4dc6f 100644 --- a/Makefile +++ b/Makefile @@ -276,7 +276,8 @@ no-dot-config-targets := $(clean-targets) \ cscope gtags TAGS tags help% %docs check% coccicheck \ $(version_h) headers headers_% archheaders archscripts \ %asm-generic kernelversion %src-pkg dt_binding_check \ - outputmakefile rustavailable rustfmt rustfmtcheck + outputmakefile rustavailable rustfmt rustfmtcheck \ + rustupoverride no-sync-config-targets := $(no-dot-config-targets) %install modules_sign kernelrelease \ image_name single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o %.rsi %.s %.symtypes %/ @@ -1611,6 +1612,7 @@ help: @echo ' (requires kernel .config; downloads external repos)' @echo ' rust-analyzer - Generate rust-project.json rust-analyzer support file' @echo ' (requires kernel .config)' + @echo ' rustupoverride - Set up a rustup override for the build directory' @echo ' dir/file.[os] - Build specified target only' @echo ' dir/file.rsi - Build macro expanded source, similar to C preprocessing.' @echo ' Run with RUSTFMT=n to skip reformatting if needed.' @@ -1735,6 +1737,11 @@ rustfmt: rustfmtcheck: rustfmt_flags = --check rustfmtcheck: rustfmt +# `rustup override` setup target +PHONY += rustupoverride +rustupoverride: + $(Q)rustup override set $(shell $(srctree)/scripts/min-tool-version.sh rustc) + # Misc # ---------------------------------------------------------------------------
On Thu, Dec 14, 2023 at 6:22 PM Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > > Or we could just provide a `rustupoverride` Make target to do this for > us [1], since we have all the information needed and would be > copy-pasteable by everybody. I can send it as a non-mangled patch and > then Viresh can redo this one on top using it. Patch at: https://lore.kernel.org/rust-for-linux/20231214222253.116734-1-ojeda@kernel.org/ Cheers, Miguel
On 14-12-23, 18:22, Miguel Ojeda wrote: > Something like v1 but a bit simpler, e.g. keeping things as they are, > but with just a sentence after the command like "If you are building > the kernel with `O=`, i.e. specifying an output directory, then you > should append `--path <builddir>`." could work. > > Or we could just provide a `rustupoverride` Make target to do this for > us [1], since we have all the information needed and would be > copy-pasteable by everybody. I can send it as a non-mangled patch and > then Viresh can redo this one on top using it. How about this ? diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst index f382914f4191..367b06f3edc2 100644 --- a/Documentation/rust/quick-start.rst +++ b/Documentation/rust/quick-start.rst @@ -39,8 +39,17 @@ If ``rustup`` is being used, enter the checked out source code directory rustup override set $(scripts/min-tool-version.sh rustc) This will configure your working directory to use the correct version of -``rustc`` without affecting your default toolchain. If you are not using -``rustup``, fetch a standalone installer from: +``rustc`` without affecting your default toolchain. + +If you are building the kernel with `O=`, i.e. specifying an output +directory, then you should append `--path <builddir>` to the above +command. + +Alternatively, you can use the ``rustupoverride`` Make target:: + + make LLVM=1 O=<builddir> rustupoverride + +If you are not using ``rustup``, fetch a standalone installer from: https://forge.rust-lang.org/infra/other-installation-methods.html#standalone
On 15/12/2023 06:48, Viresh Kumar wrote: > On 14-12-23, 18:22, Miguel Ojeda wrote: >> Something like v1 but a bit simpler, e.g. keeping things as they are, >> but with just a sentence after the command like "If you are building >> the kernel with `O=`, i.e. specifying an output directory, then you >> should append `--path <builddir>`." could work. >> >> Or we could just provide a `rustupoverride` Make target to do this for >> us [1], since we have all the information needed and would be >> copy-pasteable by everybody. I can send it as a non-mangled patch and >> then Viresh can redo this one on top using it. > > How about this ? > > diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst > index f382914f4191..367b06f3edc2 100644 > --- a/Documentation/rust/quick-start.rst > +++ b/Documentation/rust/quick-start.rst > @@ -39,8 +39,17 @@ If ``rustup`` is being used, enter the checked out source code directory > rustup override set $(scripts/min-tool-version.sh rustc) > > This will configure your working directory to use the correct version of > -``rustc`` without affecting your default toolchain. If you are not using > -``rustup``, fetch a standalone installer from: > +``rustc`` without affecting your default toolchain. > + > +If you are building the kernel with `O=`, i.e. specifying an output > +directory, then you should append `--path <builddir>` to the above > +command. > + I think we can drop the reference to the `--path <buildir>` to avoid giving too much information to the users following the guide. It doesn't seem to bring anything given users should now always go through `make rustupoverride`. > +Alternatively, you can use the ``rustupoverride`` Make target:: > + > + make LLVM=1 O=<builddir> rustupoverride > + But if I understood this correctly, the point here is that with the new target we can now abstract both cases behind the `make rustupoverride` target - i.e. we don't need to provide alternatives. So, maybe something like the following is clearer: If ``rustup`` is being used, enter the checked out source code directory, or your build directory (if you're using the `O=` option to build the kernel), and run:: make LLVM=1 rustupoverride This will configure your current directory to use the correct version of ``rustc`` without affecting your default toolchain. If you are not using ``rustup``, fetch a standalone installer from: https://forge.rust-lang.org/infra/other-installation-methods.html#standalone Tiago.
On 15-12-23, 11:14, Tiago Lam wrote: > If ``rustup`` is being used, enter the checked out source code directory, > or your build directory (if you're using the `O=` option to build the > kernel), and run:: I thought people aren't required to enter the build directory now (but just source code directory) and simply do: make LLVM=1 O=<builddir> rustupoverride > > make LLVM=1 rustupoverride Will this still work if we are in the build directory ? > This will configure your current directory to use the correct version of > ``rustc`` without affecting your default toolchain. > > If you are not using ``rustup``, fetch a standalone installer from: > > https://forge.rust-lang.org/infra/other-installation-methods.html#standalone
On Fri, Dec 15, 2023 at 12:14 PM Tiago Lam <tiagolam@gmail.com> wrote: > > I think we can drop the reference to the `--path <buildir>` to avoid > giving too much information to the users following the guide. It doesn't > seem to bring anything given users should now always go through `make > rustupoverride`. Yeah, the idea with the new target was to simplify this, rather than have it as an additional way. > But if I understood this correctly, the point here is that with the new > target we can now abstract both cases behind the `make rustupoverride` > target - i.e. we don't need to provide alternatives. Exactly. Cheers, Miguel
On Fri, Dec 15, 2023 at 12:24 PM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > I thought people aren't required to enter the build directory now (but > just source code directory) and simply do: > > make LLVM=1 O=<builddir> rustupoverride Yeah, that is correct, but we don't need to write the `O=` in the commands themselves. The idea is that 1) the commands can be easily copy-pasted, 2) commands look simple (i.e. there are many other variations and options you may pass), 3) newcomers do not need to care about `O=` (so it is extra simple for them). > Will this still work if we are in the build directory ? Both should work (as long as the initial setup in the build folder is done, of course), so I think we can simply remove the mention about "enter ..." now and simply give the command. In fact, even if Kbuild did not support that, we could still remove the "enter ...", because then the `make` would need to be run like any other target from the source tree. In other words, regardless of the answer, we could remove it thanks to the new target, unless I am missing something. Cheers, Miguel
On 15/12/2023 11:24, Viresh Kumar wrote:
[...]
> Will this still work if we are in the build directory ?
I've tried it and it does work. The build directory that's set up with
`O=` ends up with a Makefile with an `include` to the original Makefile
in my main linux source:
include $MY_WORKSPACE/linux/Makefile
(But see Miguel's reply about dropping the mention to "enter ..."
altogether)
Tiago.
On Fri, Dec 15, 2023 at 8:53 PM Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > > On Fri, Dec 15, 2023 at 12:24 PM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > > > I thought people aren't required to enter the build directory now (but > > just source code directory) and simply do: > > > > make LLVM=1 O=<builddir> rustupoverride > > Yeah, that is correct, but we don't need to write the `O=` in the > commands themselves. The idea is that 1) the commands can be easily > copy-pasted, 2) commands look simple (i.e. there are many other > variations and options you may pass), 3) newcomers do not need to care > about `O=` (so it is extra simple for them). > > > Will this still work if we are in the build directory ? > > Both should work (as long as the initial setup in the build folder is > done, of course), so I think we can simply remove the mention about > "enter ..." now and simply give the command. > > In fact, even if Kbuild did not support that, we could still remove > the "enter ...", because then the `make` would need to be run like any > other target from the source tree. FWIW. Kbuild is designed to be able to initiate 'make' from anywhere, even if the build directory is not set up. In that case, you need to use -f option to point to the top Makefile. You can enter a build directory, then do this: $ make -f <path/to/source/tree>/Makefile defconfig all Likewise, both of the following should work. 1) Enter the source directory, and $ make O=<path-to-build-directory> rustupoverride 2) Enter the build directory, and $ make -f <path-to-source-directory>/Makefile rustupoverride > In other words, regardless of the > answer, we could remove it thanks to the new target, unless I am > missing something. > > Cheers, > Miguel > -- Best Regards Masahiro Yamada
On Mon, Dec 18, 2023 at 1:07 PM Masahiro Yamada <masahiroy@kernel.org> wrote: > > FWIW. > > Kbuild is designed to be able to initiate 'make' from anywhere, > even if the build directory is not set up. > > In that case, you need to use -f option to point to the top Makefile. I meant for the command that Viresh mentioned (i.e. without `-f`), but that `-f` is meant to work is good to know, thanks! Cheers, Miguel
On Tue, Dec 12, 2023 at 8:44 AM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > Rustup override is required to be set for the build directory and not > necessarily the kernel source tree (unless the build directory is its > subdir). > > Clarify the same in quick-start guide. > > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Since we are not going to use v3 given we will not have the `rustupoverride` Make target, I have applied this one. It is also the one that got more `Reviewed-by`s, I think Andreas preferred too and Masahiro was kind enough to be OK applying this one instead of his (which would need to be rebased and submitted to the list), so I went with that one. Tiago's concern is still there though (i.e. the script is relative to the source tree), but we can improve things further later (perhaps if we add a script for this sort of thing). Applied to `rust-next` (reworded and fixed quotes for `--path` and `set`) -- thanks everyone! Cheers, Miguel
diff --git a/Documentation/rust/quick-start.rst b/Documentation/rust/quick-start.rst index f382914f4191..7ea931f74e09 100644 --- a/Documentation/rust/quick-start.rst +++ b/Documentation/rust/quick-start.rst @@ -33,14 +33,18 @@ A particular version of the Rust compiler is required. Newer versions may or may not work because, for the moment, the kernel depends on some unstable Rust features. -If ``rustup`` is being used, enter the checked out source code directory -and run:: +If ``rustup`` is being used, enter the kernel build directory (or use +`--path=<build-dir>` argument to the `set` sub-command) and run:: rustup override set $(scripts/min-tool-version.sh rustc) This will configure your working directory to use the correct version of -``rustc`` without affecting your default toolchain. If you are not using -``rustup``, fetch a standalone installer from: +``rustc`` without affecting your default toolchain. + +Note that the override applies to the current working directory (and its +sub-directories). + +If you are not using ``rustup``, fetch a standalone installer from: https://forge.rust-lang.org/infra/other-installation-methods.html#standalone