All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	Markus Heiser <markus.heiser@darmarit.de>
Cc: linux-doc@vger.kernel.org
Subject: Re: Building directly with sphinx
Date: Mon, 25 May 2020 15:08:40 +0300	[thread overview]
Message-ID: <87367o2p4n.fsf@intel.com> (raw)
In-Reply-To: <20200521175122.zcyoa7zz33anokit@chatter.i7.local>

On Thu, 21 May 2020, Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> On Thu, May 21, 2020 at 10:35:51AM +0200, Markus Heiser wrote:
>> > 
>> > I was playing around with readthedocs.org recently and wanted to see if
>> > I could build kernel docs there. I cannot directly run "make htmldocs"
>> > there, and it proved to be quite tricky to make sphinx do the right
>> > thing without all the things that are being defined in the Makefile.
>> > 
>> > Is it possible at all, or am I wasting my time?
>> 
>> It is wasting time ;) .. The Makefile targets do build intermedaiate
>> files using perl and other scripts, this will never work on RTD.
>
> Okay, I'd suspected as much after poking around things a bit. Another 
> possibility would be to have a separate repository where we commit the 
> doc tree (after it's massaged into the "ready to be built with sphinx" 
> condition). We could run this automatically on our end on each mainline 
> release, but it's certainly not a necessity.

FWIW, when I was developing the Sphinx documentation build for the
kernel, I carefully tried to ensure everything would build directly, and
consequently also at readthedocs.org. I kept testing it at RTD too.

For this reason I kept resisting the addition of any Makefile trickery,
and insisting we should do everything through Sphinx. This would have
meant writing Sphinx extensions for all the hacks people wanted to
add. But it would also have lead to a self-contained system with fewer
moving parts, which I thought was worth pursuing. And, obviously, would
have made it possible to host the documentation at RTD.

I failed. Stuff just keeps piling up in the Makefiles.

In fairness, the kernel documentation build was growing too big even for
RTD. It kept timing out and/or consuming too much resources. I believe
that would have been possible to sort out with the RTD maintainers,
given the possibility to host kernel documentation, but there was no
point in pursuing this since the docs wouldn't build directly anyway.

BR,
Jani.


>> FWIW: in other projects I worked some time with RTD but at the end
>> I gave up: If you have e.g. auto generated content in your build
>> process which is not generated by the python developer-mainstream
>> tools, RTD gives you too little freedom to implement your more
>> or less complex build procedures.  And .. often I get the RTD-Oops
>> links from search engines ..  RTD is (my experience is a  while
>> ago; "was") not very comfortable to to rebind obsolete URLs to
>> new content.
>> 
>> Overall I think kernel.org does a good job .. since years, no need
>> for additional RTD confusions;
>> 
>>    https://www.kernel.org/doc/html/latest/
>
> Glad to hear it. My primary interest in getting it hooked up with RTD 
> was just from the perspective of creating an external mirror for folks 
> who are already using RTD. For now, I'm going to shelve this effort and 
> just continue building docs straight from the tree on our end.
>
> Thanks for your help!
>
> -K

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2020-05-25 12:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20 21:53 Building directly with sphinx Konstantin Ryabitsev
2020-05-21  8:35 ` Markus Heiser
2020-05-21 17:51   ` Konstantin Ryabitsev
2020-05-25 12:08     ` Jani Nikula [this message]
2020-05-26 17:31       ` Konstantin Ryabitsev

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=87367o2p4n.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=konstantin@linuxfoundation.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=markus.heiser@darmarit.de \
    /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.