linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
	Matthew Wilcox <willy@infradead.org>,
	linux-doc@vger.kernel.org,
	Markus Heiser <markus.heiser@darmarit.de>
Subject: Re: [PATCH RFC] Make the docs build "work" with Sphinx 3.x
Date: Wed, 23 Sep 2020 11:01:06 +0200	[thread overview]
Message-ID: <20200923110106.192e313f@coco.lan> (raw)
In-Reply-To: <20200922105656.11043bd9@lwn.net>

Em Tue, 22 Sep 2020 10:56:56 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:

> On Tue, 22 Sep 2020 10:23:46 +0300
> Jani Nikula <jani.nikula@linux.intel.com> wrote:
> 
> > > Should we be converting the kernel-doc script to output 3.0-style markup
> > > for structs?  
> > 
> > IIUC it's not backwards compatible with Sphinx pre-3.0, so you'd either
> > have to require Sphinx 3.0 or have kernel-doc emit both, depending on
> > the Sphinx version.
> 
> Certainly before requiring 3.0 we should, like, actually make it work with
> 3.0...  People with time to do that appear to be rather scarce at the
> moment, though.  I'll get to it eventually but I have a few other things
> on my plate as well.

Tried to build now with Sphinx 3.2.1. There are thousands of warnings:

	build succeeded, 3423 warnings.

Like those:

	Documentation/driver-api/basics.rst: WARNING: Duplicate C declaration, also defined in 'core-api/workqueue'.
	Declaration is 'unsigned long delay'.

And those:

	./include/uapi/linux/firewire-cdev.h:38: WARNING: Type must be either just a name or a typedef-like declaration.
	If just a name:
	  Error in declarator or parameters
	  Invalid C declaration: Expected identifier in nested name, got keyword: struct [error at 6]
	    struct fw_cdev_event_iso_interrupt
	    ------^
	If typedef-like declaration:
	  Error in declarator or parameters
	  Invalid C declaration: Expected identifier in nested name. [error at 34]
	    struct fw_cdev_event_iso_interrupt
	    ----------------------------------^

If I'm not mistaken, one of the reasons why cdomain was added is
due to the duplicate C declaration.

-

I guess changing kernel-doc to produce Sphinx 3.x syntax and
raise the bar requiring 3.0 to be the minimal version would be
one alternative, but this won't solve the duplicated C declarations. 

Does Sphinx 3.x have some way to enable "local" C references?

Another one could be to make cdomain compatible with 3.x and
make it handle the differences. Not sure how easy/hard would be
to do that.

Thanks,
Mauro

  reply	other threads:[~2020-09-23  9:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-04 16:29 [PATCH RFC] Make the docs build "work" with Sphinx 3.x Jonathan Corbet
2020-09-21 22:26 ` Matthew Wilcox
2020-09-22  7:19   ` Mauro Carvalho Chehab
2020-09-22  7:23   ` Jani Nikula
2020-09-22 16:56     ` Jonathan Corbet
2020-09-23  9:01       ` Mauro Carvalho Chehab [this message]
2020-09-23 11:53         ` Mauro Carvalho Chehab
2020-09-23 14:02           ` Mauro Carvalho Chehab
2020-09-24  7:02             ` Mauro Carvalho Chehab
2020-09-24 11:22               ` [PATCH 0/2] Start supporting builds with Sphinx 3.1+ Mauro Carvalho Chehab
2020-09-24 11:22                 ` [PATCH 1/2] docs: cdomain.py: add support for two new Sphinx 3.1+ tags Mauro Carvalho Chehab
2020-09-24 15:43                   ` Jonathan Corbet
2020-09-24 16:13                     ` Mauro Carvalho Chehab
2020-09-24 16:22                       ` Jonathan Corbet
2020-09-25  4:14                         ` Mauro Carvalho Chehab
2020-09-24 11:22                 ` [PATCH 2/2] media: docs: make CEC documents compatible with Sphinx 3.1+ Mauro Carvalho Chehab
2020-09-24 12:47     ` [PATCH RFC] Make the docs build "work" with Sphinx 3.x 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=20200923110106.192e313f@coco.lan \
    --to=mchehab@kernel.org \
    --cc=corbet@lwn.net \
    --cc=jani.nikula@linux.intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=markus.heiser@darmarit.de \
    --cc=willy@infradead.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).