[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANiq72kfpdNdCXtxFM-YVLuOp34u_edieX0q_a94-5kAxdGRWg@mail.gmail.com>
Date: Thu, 21 Dec 2023 22:38:49 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Miguel Ojeda <ojeda@...nel.org>
Cc: Wedson Almeida Filho <wedsonaf@...il.com>, Alex Gaynor <alex.gaynor@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...sung.com>,
Alice Ryhl <aliceryhl@...gle.com>, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org, patches@...ts.linux.dev,
FUJITA Tomonori <fujita.tomonori@...il.com>
Subject: Re: [PATCH] rust: support `srctree`-relative links
On Sat, Dec 16, 2023 at 12:54 AM Miguel Ojeda <ojeda@...nel.org> wrote:
>
> Some of our links use relative paths in order to point to files in the
> source tree, e.g.:
>
> //! C header: [`include/linux/printk.h`](../../../../include/linux/printk.h)
> /// [`struct mutex`]: ../../../../include/linux/mutex.h
>
> These are problematic because they are hard to maintain and do not support
> `O=` builds.
>
> Instead, provide support for `srctree`-relative links, e.g.:
>
> //! C header: [`include/linux/printk.h`](srctree/include/linux/printk.h)
> /// [`struct mutex`]: srctree/include/linux/mutex.h
>
> The links are fixed after `rustdoc` generation to be based on the absolute
> path to the source tree.
>
> Essentially, this is the automatic version of Tomonori's fix [1],
> suggested by Gary [2].
>
> Suggested-by: Gary Guo <gary@...yguo.net>
> Reported-by: FUJITA Tomonori <fujita.tomonori@...il.com>
> Closes: https://lore.kernel.org/r/20231026.204058.2167744626131849993.fujita.tomonori@gmail.com [1]
> Fixes: 48fadf440075 ("docs: Move rustdoc output, cross-reference it")
> Link: https://lore.kernel.org/rust-for-linux/20231026154525.6d14b495@eugeo/ [2]
> Signed-off-by: Miguel Ojeda <ojeda@...nel.org>
Applied to `rust-next` -- thanks everyone!
By the way, since I didn't mention it: this obviously requires the
source tree to be available at its path, so we may want to improve on
that later (e.g. exporting the needed files in the output folder), but
it is a strict improvement since it fixes the immediate issue, it
cleans the paths already reducing the maintenance burden (i.e. we can
keep the syntax even if we change the rest) and is a smaller change if
we decide to send it to stable later.
Cheers,
Miguel
Powered by blists - more mailing lists