linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Corbet <corbet@lwn.net>
To: Akira Yokosawa <akiyks@gmail.com>,
	Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Carlos Bilbao <carlos.bilbao@amd.com>,
	ojeda@kernel.org, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, bilbao@vt.edu,
	konstantin@linuxfoundation.org, Akira Yokosawa <akiyks@gmail.com>
Subject: Re: [PATCH v2] docs: Integrate rustdoc into Rust documentation
Date: Tue, 06 Dec 2022 08:02:04 -0700	[thread overview]
Message-ID: <87pmcwlgnn.fsf@meer.lwn.net> (raw)
In-Reply-To: <e3523f33-847b-81da-7b20-83ee54597d9f@gmail.com>

Akira Yokosawa <akiyks@gmail.com> writes:

> Well, I'm actually worrying about additional TAT when I want to test
> a particular change in a .rst file and test-build under the relevant
> subdirectory using a command, e.g., "make SPHINXDIRS=doc-guide htmldocs".
>
> This completes almost instantly when CONFIG_RUST is not set.
>
> With CONFIG_RUST=y, in my test, it runs RUSTDOC even when rustdoc is
> already generated once, as shown below:

This is something that would be nice to avoid if we can; narrowing
things with SPHINXDIRS should avoid building anything that the user
isn't asking for.  I'm not sure how much makefile pain would be required
to make that happen...Documentation/Makefile is not the easiest place to
make changes, alas.

> I think you can add a new target in the top-devel Makefile which
> runs both rustdoc and htmldocs for CIs. Something like 'htmldocsboth'
> or 'htmldocsall'???
>
> htmldocs and other *docs targets are the most primitive ones for
> running Sphinx, so my gut feeling tells me _not_ to contaminate
> htmldocs with rustdoc or vice versa.

Well, I *would* like for a bare "make htmldocs" to make *all* of the
docs; I don't think Rust should be special in that regard.

>> (It is also why I wondered above about
>> `CONFIG_WARN_MISSING_DOCUMENTS`: if `Documentation/` intended to
>> require a config as a whole, then it would be fine. I assume that is
>> not the case, though, but not doing the sync is nevertheless a bit
>> confusing)
>
> I have no idea. (Note: I was not around when the kernel documentation
> transitioned to Sphinx.)

I think we're just seeing the implementation as was rammed in by
somebody in a hurry; I don't doubt it could be improved.

Thanks,

jon  (currently traveling and scrambling to get ready for the merge window)

  reply	other threads:[~2022-12-06 15:06 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-30 22:08 [PATCH] docs: Integrate rustdoc into Rust documentation Carlos Bilbao
2022-12-01 12:42 ` Miguel Ojeda
2022-12-01 20:40   ` Carlos Bilbao
2022-12-02 16:27     ` Miguel Ojeda
2022-12-02 16:30       ` Carlos Bilbao
2022-12-01 20:48 ` [PATCH v2] " Carlos Bilbao
2022-12-05  1:06   ` Akira Yokosawa
2022-12-05 16:08     ` Miguel Ojeda
2022-12-06 13:32       ` Akira Yokosawa
2022-12-06 15:02         ` Jonathan Corbet [this message]
2022-12-06 15:39         ` Miguel Ojeda
2022-12-05 16:36     ` Carlos Bilbao
2022-12-06 14:22       ` Akira Yokosawa
2022-12-06 14:55         ` Carlos Bilbao
2022-12-06 15:01         ` Carlos Bilbao
2022-12-06 15:31   ` [PATCH v3 0/2] " Carlos Bilbao
2022-12-06 15:31     ` [PATCH v3 1/2] docs: Move rustdoc output, cross-reference it Carlos Bilbao
2022-12-06 22:56       ` Akira Yokosawa
2022-12-07  8:27       ` Jani Nikula
2022-12-07 13:49         ` Carlos Bilbao
2022-12-07 14:15           ` Jani Nikula
2022-12-07 15:06             ` Carlos Bilbao
2022-12-07 19:33           ` Jonathan Corbet
2022-12-06 15:31     ` [PATCH v3 2/2] docs: Integrate rustdoc generation into htmldocs Carlos Bilbao
2022-12-06 23:11       ` Akira Yokosawa
2022-12-07  0:06         ` Randy Dunlap

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=87pmcwlgnn.fsf@meer.lwn.net \
    --to=corbet@lwn.net \
    --cc=akiyks@gmail.com \
    --cc=bilbao@vt.edu \
    --cc=carlos.bilbao@amd.com \
    --cc=konstantin@linuxfoundation.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).