From: ludo@gnu.org (Ludovic Courtès)
To: Eric Bavier <ericbavier@openmailbox.org>
Cc: guix-devel@gnu.org
Subject: Re: [PATCH] gnu: unison: Add "doc" output.
Date: Fri, 08 Jan 2016 11:19:34 +0100 [thread overview]
Message-ID: <87oacwl6fd.fsf@gnu.org> (raw)
In-Reply-To: <20160108011341.263e863a@openmailbox.org> (Eric Bavier's message of "Fri, 8 Jan 2016 01:13:41 -0600")
Eric Bavier <ericbavier@openmailbox.org> skribis:
> From c8a0086db4d78091e06326a5ffe55a7bf2543091 Mon Sep 17 00:00:00 2001
> From: Eric Bavier <bavier@member.fsf.org>
> Date: Fri, 18 Dec 2015 19:29:22 -0600
> Subject: [PATCH] gnu: unison: Add "doc" output.
>
> * gnu/packages/ocaml.scm (unison)[source]: Use svn-fetch with snippet.
> [outputs]: New field.
> [native-inputs]: Add ghostscript, texlive, hevea, and lynx.
> [arguments]: Add 'install-doc phase.
[...]
> + (snippet
> + `(begin
> + ;; The svn revision in the release tarball appears to be
> + ;; artificially manipulated in order to set the desired point
> + ;; version number. Because the point version is calculated during
> + ;; the build, we can offset pointVersionOrigin by the desired
> + ;; point version and write that into "Rev: %d". We do this rather
> + ;; than hardcoding the necessary revision number, for
> + ;; maintainability.
Fun. :-)
> + (with-atomic-file-replacement "src/mkProjectInfo.ml"
> + (lambda (in out)
> + (let ((pt-ver (string->number (third (string-split ,version #\.))))
> + (pt-rx (make-regexp "^let pointVersionOrigin = ([0-9]+)"))
> + (rev-rx (make-regexp "Rev: [0-9]+")))
> + (let loop ((pt-origin #f))
> + (let ((line (read-line in 'concat)))
> + (cond
> + ((regexp-exec pt-rx line)
> + => (lambda (m)
> + (begin
‘begin’ can be omitted here…
> + ((regexp-exec rev-rx line)
> + => (lambda (m)
> + (begin
… and here.
> + (for-each (lambda (f)
> + (install-file f doc))
> + (map (lambda (ext)
> + (string-append
> + "doc/unison-manual." ext))
> + '("ps" "pdf" "dvi" "html")))
What about installing only HTML?
I find that HTML (and Info, and man) is more convenient to read on-line
than PDFs. We rarely include PDF documentation in packages.
Of course, avoiding PDF/PS/DVI allows us to remove the dependency on
TeX Live. Last, from discussions I heard at the Reproducible Build
Summit, I think DVIs and maybe PS/PDFs are not bit-reproducible
out-of-the-box.
WDYT?
Maybe we should have a policy on how to choose the installed
documentation formats.
Thanks for finding out how to build documentation from source!
Ludo’.
next prev parent reply other threads:[~2016-01-08 10:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-19 1:42 [PATCH] gnu: unison: Add "doc" output Eric Bavier
2015-12-20 20:57 ` Leo Famulari
2015-12-20 22:11 ` Ludovic Courtès
2015-12-21 4:01 ` Eric Bavier
2015-12-21 10:39 ` Ludovic Courtès
2016-01-08 7:13 ` Eric Bavier
2016-01-08 10:19 ` Ludovic Courtès [this message]
2016-01-17 6:28 ` Eric Bavier
2016-01-18 9:49 ` Ludovic Courtès
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=87oacwl6fd.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=ericbavier@openmailbox.org \
--cc=guix-devel@gnu.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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
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.