public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: "R. Diez" <rdiezmail-newlib@yahoo.de>
Cc: "newlib@sourceware.org" <newlib@sourceware.org>
Subject: Re: [PATCH] libgloss: doc: generate single page & split html manuals
Date: Wed, 29 Nov 2023 03:45:06 -0500	[thread overview]
Message-ID: <ZWb6Eoh2dJrpkizl@vapier> (raw)
In-Reply-To: <846352090.13404951.1697463896904@mail.yahoo.com>

[-- Attachment #1: Type: text/plain, Size: 2105 bytes --]

On 16 Oct 2023 13:44, R. Diez wrote:
> >>> [...]
> >>> add an extra rule to also generate the split page manual.
> 
> >> Is 'html-local' the new target?
> 
> > this is an internal Automake hook point.  people still run `make html` and
> > they'll get both forms of the manual.
> 
> If I understood it correctly, you are not actually adding an extra rule, but injecting an extra step in the standard 'html' rule.

i don't know if you're trying to understand the internals, or just form a mental
model of how this comes together.  from a makefile perspective, it is a new rule
that you can `make html-local` if you really want.  automake will add a dep on
the new rule to the standard html rule iff the rule exists so that people don't
have to run the explicit xxx-local rules.

> The makefile will then be generating both 'single' and 'split' HTML documentation variants at once. This will usually be a waste of CPU time and disk space, will it not? I guess most people would normally want one version or the other, but not both.

currently, the html manual isn't built by default.  it's only generated if the
user runs `make html` explicitly.

but sure, if the user only wants one version and not the other, it's technically
a waste of time.  considering the manual generation takes <150ms on my system
per variant, i don't think it's worth the time debating this.  running configure
takes significantly longer.

other projects haven't really provided a choice to people -- they generate both.

> The 'html' target, and the notion single/split, seems like a standard Automake concept, but I am not familiar with it yet. Is the Automake user supposed to specify via MAKEINFOFLAGS whether to generate a single or split variant? What happens if the user specifies MAKEINFOFLAGS=--no-split or MAKEINFOFLAGS=--split=chapter ?

the single/split is a texinfo thing, not automake.  the point of generating both
of them is to make it easier for people to have access to whichever version they
want, and to make it easier for us producing the release docs for the website.
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2023-11-29  8:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-15  8:22 Mike Frysinger
2023-10-16  9:31 ` R. Diez
2023-10-16 10:16   ` Mike Frysinger
2023-10-16 13:44     ` R. Diez
2023-11-29  8:45       ` Mike Frysinger [this message]

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=ZWb6Eoh2dJrpkizl@vapier \
    --to=vapier@gentoo.org \
    --cc=newlib@sourceware.org \
    --cc=rdiezmail-newlib@yahoo.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 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).