From: Liliana Marie Prikler <liliana.prikler@gmail.com>
To: Andrew Tropin <andrew@trop.in>
Cc: 57280@debbugs.gnu.org
Subject: [bug#57280] [PATCH 0/3] Add documentation-files argument to emacs build system.
Date: Fri, 02 Sep 2022 16:52:57 +0200 [thread overview]
Message-ID: <c37a6706dc15cbb80b0f27122ce497e6f3f6b272.camel@gmail.com> (raw)
In-Reply-To: <87czcd3md9.fsf@trop.in>
Hi,
Am Freitag, dem 02.09.2022 um 17:02 +0300 schrieb Andrew Tropin:
> Picked (guix build emacs-utils) for now, it's done to avoid huge
> rebuilds, while testing, later we can move it to (guix build utils).
>
> Also, temporary added pandoc and texinfo to native-inputs for
> emacs-build-system, otherwise I would need to update inputs for
> almost every emacs-* package. Need to figure out what to do with
> this.
I still don't like that we need pandoc and texinfo as implicit inputs.
There ought to be a better solution than this.
> >
> > > Attaching the latest version of the documentation-files patch I
> > > have
> > Looking at this patch, perhaps we'd also have to allow customizing
> > command line options. Also, as for installing, I think this should
> > be
> > handled by the install phase, which already has includes
> > "^[^/]*\\.info$" and "^doc/.*\\.info$" by default. Thus, you only
> > need
> > to build documentation before the install phase.
>
> That's right, but in the new iteration (v3) of build-documentation
> phase I use find-root-library-file, which expects to be executed when
> elpa directory is already available, so I can't do it before install
> phase and need to manually install info files.
>
> Also, current build phases order is a little confusing, a lot of
> builds happens after install phase, directly in output directory:
>
> `set-SOURCE-DATE-EPOCH'
> `set-paths'
> `install-locale'
> `unpack'
> `expand-load-path'
> `patch-usr-bin-file'
> `patch-source-shebangs'
> `patch-generated-file-shebangs'
> `check'
> `install'
> `make-autoloads'
> `enable-autoloads-compilation'
> `patch-el-files'
> `ensure-package-description'
> `build'
> `validate-compiled-autoloads'
> `build-documentation'
> `move-doc'
> `patch-shebangs'
> `strip'
> `validate-runpath'
> `validate-documentation-location'
> `delete-info-dir-file'
> `patch-dot-desktop-files'
> `make-dynamic-linker-cache'
> `install-license-files'
> `reset-gzip-timestamps'
> `compress-documentation'
>
> What if instead of install phase we will use create-tmp-lisp-and-
> documentation-directories phase (or something
> more meaningful) to make a temporary directory, where we will build
> all the stuff and after that, at the end of the build process will
> install everything from this temporary directory to the store? This
> way emacs-build-system will become more usual and easier to
> understand andpredict.
I don't think we would need to do staged installations. As for why we
don't build in the temporary directory, I do not know, I merely
inherited that code.
> +(define* (build-documentation-texinfo
> + #:key
> + (files '())
> + (command '("makeinfo" "--no-split")))
> + "Don't forget to add texinfo into list of inputs for the package."
> + (lambda* (#:key outputs #:allow-other-keys)
> + (for-each (lambda (f) (apply invoke (append command (list f))))
> files)))
This is hardly specific to emacs, is it?
Also, append is usually a code smell. Can't we (apply invoke
"makeinfo" file options)?
> +(define* (convert-documentation
> + #:key
> + (mapping '())
> + (command '("pandoc")))
> + "Don't forget to add pandoc into list of inputs for the package."
> + (lambda* (#:key outputs #:allow-other-keys)
> + (for-each (lambda (p) (apply invoke
> + (append command
> + (list (car p) "-o" (cdr
> p)))))
> + mapping)))
As above.
> +(define* (build-documentation-org
> + #:key
> + (files '()))
This one is emacs-specific due to emacs-batch-script and can remain
there.
> + (add-after 'validate-compiled-autoloads 'move-doc move-doc)
> + (add-before 'move-doc 'build-documentation
> build-documentation)))
I don't think that we'll have to add this phase once we've added the
helpers. And as previously discussed, we'd have to build the
documentation before install.
Cheers
next prev parent reply other threads:[~2022-09-02 14:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87wnb5lhyr.fsf@trop.in>
[not found] ` <107d9c475d47842d67db4f0a7d85d63ae11f9f3c.camel@gmail.com>
2022-08-19 3:33 ` [bug#57280] [PATCH 0/3] Add documentation-files argument to emacs build system Andrew Tropin
2022-08-19 4:19 ` Liliana Marie Prikler
2022-08-19 6:21 ` Andrew Tropin
2022-08-19 15:39 ` Liliana Marie Prikler
2022-08-26 14:33 ` Andrew Tropin
2022-08-29 16:38 ` Liliana Marie Prikler
2022-08-30 8:15 ` Andrew Tropin
2022-08-30 8:28 ` Liliana Marie Prikler
2022-08-31 9:36 ` Andrew Tropin
2022-08-31 10:07 ` Liliana Marie Prikler
2022-09-02 14:02 ` Andrew Tropin
2022-09-02 14:52 ` Liliana Marie Prikler [this message]
2023-04-26 4:40 ` bug#57280: " Andrew Tropin
2022-08-18 18:35 [bug#57280] " Andrew Tropin
2022-08-18 19:31 ` Liliana Marie Prikler
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c37a6706dc15cbb80b0f27122ce497e6f3f6b272.camel@gmail.com \
--to=liliana.prikler@gmail.com \
--cc=57280@debbugs.gnu.org \
--cc=andrew@trop.in \
/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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
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).