public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: "Martin Liška" <mliska@suse.cz>,
	"Xi Ruoyao" <xry111@linuxfromscratch.org>,
	"Sandra Loosemore" <sandra@codesourcery.com>,
	"GCC Patches" <gcc-patches@gcc.gnu.org>,
	"GCC Development" <gcc@gcc.gnu.org>
Subject: Re: Announcement: Porting the Docs to Sphinx - 9. November 2022
Date: Thu, 20 Oct 2022 18:47:23 +0200	[thread overview]
Message-ID: <Y1F7m7fTAnLScqxs@tucnak> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2210201635490.71947@digraph.polyomino.org.uk>

On Thu, Oct 20, 2022 at 04:43:06PM +0000, Joseph Myers wrote:
> On Thu, 20 Oct 2022, Martin Liška wrote:
> 
> > > Also, but not strictly part of the release issue:
> > > 
> > > (d) Builds with missing or old Sphinx should work regardless of whether 
> > > such files are in the source directory - but if they aren't in the source 
> > > directory, the effect of missing or old Sphinx (detected at configure 
> > > time) should be to disable building and installing documentation.
> > 
> > All right Joseph, is it something you're willing to help me once we start
> > using Sphinx? Apparently, there will be many consequent steps after we switch.
> 
> Sure, but most of the conditionals are *already* present, just need 
> updating as part of the Sphinx transition.  E.g. gcc/Makefile.in has 
> BUILD_INFO and GENERATED_MANPAGES conditionals based on configure tests 
> for whether relevant tools are present and new enough; the rules for 
> $(DESTDIR)$(infodir)/%.info quietly allow the info files not to be 
> present, so installing also works without the info files or tools to build 
> them, and the rules for installing man pages similarly ignore errors; and 
> there are srcinfo and srcman rules, enabled based on @GENINSRC@, to copy 
> those built files to the source directory, which are what's used when 
> --enable-generated-files-in-srcdir is used as part of building a release 
> tarball.
> 
> The main thing I've suggested that I think may actually be new is an error 
> for trying to build a release tarball without new-enough Sphinx (I think 
> the current rules would quietly not copy info / man pages to the source 
> directory if build tools were missing - but having those tools missing 
> when building a release tarball is much less likely than not having 
> new-enough Sphinx).

But perhaps that test should go to maintainer-scripts/gcc_release.
Can be either of the form of checking if Sphinx is new enough, or checking
of make actually built the documentation before creating the tarballs.

	Jakub


  reply	other threads:[~2022-10-20 16:47 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31 14:06 Porting the Docs to Sphinx - project status Martin Liška
2022-02-04 13:40 ` Matthias Klose
2022-03-08 15:59   ` Martin Liška
2022-08-02 12:48 ` Martin Liška
2022-10-17 13:28   ` Announcement: Porting the Docs to Sphinx - 9. November 2022 Martin Liška
2022-10-17 14:16     ` Paul Iannetta
2022-10-19  7:24       ` Martin Liška
2022-10-19  8:13         ` Paul Iannetta
2022-10-19  9:22           ` Martin Liška
2022-10-19 16:42             ` Joseph Myers
2022-10-20 11:13               ` Martin Liška
2022-10-17 22:26     ` Sandra Loosemore
2022-10-19 11:09       ` Martin Liška
2022-10-19 12:45         ` Martin Liška
2022-10-19 16:30         ` Sandra Loosemore
2022-10-20 11:26           ` Martin Liška
2022-10-20  2:26     ` Xi Ruoyao
2022-10-20 11:27       ` Martin Liška
2022-10-20 11:49         ` Xi Ruoyao
2022-10-20 11:53           ` Martin Liška
2022-10-20 11:55             ` Xi Ruoyao
2022-10-20 12:26               ` Martin Liška
2022-10-20 15:35         ` Joseph Myers
2022-10-20 15:50           ` Martin Liška
2022-10-20 16:43             ` Joseph Myers
2022-10-20 16:47               ` Jakub Jelinek [this message]
2022-11-08 13:55                 ` Announcement: Porting the Docs to Sphinx - tomorrow Martin Liška
2022-11-08 18:44                   ` Sam James
2022-11-09  0:00                     ` Joseph Myers
2022-11-09  0:06                       ` Sam James
2022-11-09  7:49                         ` Richard Biener
2022-11-09 10:18                           ` Mark Wielaard
2022-11-09 17:11                           ` Joseph Myers
2022-11-09 17:16                             ` Richard Biener
2022-11-11 20:52                   ` Gerald Pfeifer
2022-11-11 21:10                     ` Sandra Loosemore
2022-11-13 15:44                       ` Martin Liška
2022-11-09 14:45               ` Announcement: Porting the Docs to Sphinx - 9. November 2022 Martin Liška
2022-11-09 17:14                 ` Joseph Myers
2022-11-10 13:05                   ` Martin Liška
2022-11-10 13:50                     ` Richard Biener
2022-11-11 23:05     ` David Malcolm

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=Y1F7m7fTAnLScqxs@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gcc@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=mliska@suse.cz \
    --cc=sandra@codesourcery.com \
    --cc=xry111@linuxfromscratch.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 read-only IMAP folder(s) and NNTP newsgroup(s).