All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Carlos Bilbao <carlos.bilbao@kernel.org>,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	linux-kernel@vger.kernel.org, Miguel Ojeda <ojeda@kernel.org>
Subject: Re: [PATCH 0/1] fix rustdoc build detection
Date: Mon, 24 Nov 2025 09:18:11 +0100	[thread overview]
Message-ID: <20251124091811.47abd0a9@foz.lan> (raw)
In-Reply-To: <CANiq72nhrQsUcxm-1bsBEaGVbRgmAC=mVxrQ+A7TLcVuOer9oQ@mail.gmail.com>

Em Mon, 24 Nov 2025 02:51:40 +0100
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> escreveu:

> On Fri, Nov 21, 2025 at 10:41 AM Mauro Carvalho Chehab
> <mchehab+huawei@kernel.org> wrote:
> >
> > I'm not talking about stop using rustdoc. I'm talking about using
> > it to output on a format that Sphinx can understand, and let Sphinx
> > do the final output, solving cross-references.  
> 
> By stop using `rustdoc` I meant its "normal" (HTML) output, i.e. the
> webpage with all its features and so on.

I see.

> The JSON support is unstable so far:
> 
>     https://github.com/rust-lang/rust/issues/76578

From the issue timestamps, it seems that it doesn't have a high
priority.

> And even then, I imagine it will always still require a kernel config,
> so that isn't an advantage either.

This doesn't seem to be an issue itself, as a new kernel config is easy 
to add.

> Thus trying to mimic what `rustdoc` does is probably going to be a lot
> of work to maintain, to likely get a worse result than what `rustdoc`
> already does.

Perhaps one solution would be to write a new output plugin to make
rustdoc produce a better output format that could be easily mapped
by a Sphinx plugin (like producing an output on an enriched text
format like Markdown or ReST).

I can't evaluate how easy/hard would be to do that, as I'm not
familiar with Rust toolset.

> Something that would work without a config could be way more
> interesting for us to integrate into Sphinx.

At Sphinx side, it won't be hard to pick references from rustdoc.

At kernel_include extension:

	https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/sphinx/kernel_include.py

I added a logic there to detect unsolved cross-references.

Currently, it just warns about unsolved references, but it won't 
be hard to modify a similar logic to solve it, pointing to a
rustdoc reference (if those are stable enough).

Doing the reverse can be trickier, though: internally, Sphinx
maps them via a C domain. The output plugin (html, pdf, ...)
is what converts such reference into an html (or pdf) tag.
Such mapping is version dependent.

There was a major rewrite at eh C domain on Sphinx 3.0 which
changed such mapping, but other versions may have changed it as well.

Also, there is an open issue that will likely change it once
fixed:

	https://github.com/sphinx-doc/sphinx/issues/7819
	https://github.com/sphinx-doc/sphinx/issues/8241

(last one closed as duplicate of #7819)

So, creating cross-references from rustdoc to Sphinx could
be tricky and hard to maintain, as it may require some checks
at rust/rustdoc side to verify Sphinx version.

Thanks,
Mauro

  reply	other threads:[~2025-11-24  8:18 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-17  9:12 [PATCH 0/1] fix rustdoc build detection Mauro Carvalho Chehab
2025-11-17  9:12 ` [PATCH 1/1] docs: makefile: move rustdoc check to the build wrapper Mauro Carvalho Chehab
2025-11-17  9:20   ` Miguel Ojeda
2025-11-17 11:04     ` Mauro Carvalho Chehab
2025-11-18 16:38       ` Jonathan Corbet
2025-11-18 19:11         ` Mauro Carvalho Chehab
2025-11-18 20:32           ` Mauro Carvalho Chehab
2025-11-18 21:34             ` Miguel Ojeda
2025-11-18 21:40           ` Miguel Ojeda
2025-11-20 20:13             ` Mauro Carvalho Chehab
2025-11-17  9:19 ` [PATCH 0/1] fix rustdoc build detection Miguel Ojeda
2025-11-17 10:48   ` Mauro Carvalho Chehab
2025-11-17 11:22     ` Miguel Ojeda
2025-11-17 11:25       ` Miguel Ojeda
2025-11-17 12:32       ` Mauro Carvalho Chehab
2025-11-18 22:02         ` Miguel Ojeda
2025-11-21  9:40           ` Mauro Carvalho Chehab
2025-11-24  1:51             ` Miguel Ojeda
2025-11-24  8:18               ` Mauro Carvalho Chehab [this message]
2025-11-24  8:34                 ` Mauro Carvalho Chehab
2025-11-18 23:23       ` Carlos Bilbao
2025-11-21  9:12         ` Mauro Carvalho Chehab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251124091811.47abd0a9@foz.lan \
    --to=mchehab+huawei@kernel.org \
    --cc=carlos.bilbao@kernel.org \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=ojeda@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.