From: Ricardo Wurmus <rekado@elephly.net>
To: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
Cc: help-guix@gnu.org
Subject: Re: About packaging documentation
Date: Fri, 02 Apr 2021 23:56:27 +0200 [thread overview]
Message-ID: <874kgo1hbo.fsf@elephly.net> (raw)
In-Reply-To: <df270eac-ab31-35d5-d603-6e7a9ba9d190@posteo.de>
Hi Zelphir,
> (1) The cookbook does not even mention the guile-build-system. […]
> I guess this is, because the cookbook tries to be generic in a way, to apply to
> all languages, if only one uses autotools, as those are applicable to all
> languages.
No, you’re overthinking it :) The cookbook is pretty short. It started
because blog posts eventually go stale, so having some of these useful
blog posts updated with Guix seemed like a good idea.
The cookbook is supposed to include useful tutorials, recipes, extensive
examples — all stuff that would bloat up the reference manual or make it
lose scope.
The fact that the cookbook doesn’t mention the guile-build-system is due
to two reasons:
1) it’s not a reference manual, but a collection of tutorials
2) nobody contributed a tutorial involving the guile-build-system.
1 is by design, but 2 is not. We would certainly add a tutorial for
simple Guile packages if someone contributed it.
> (2) The hello package example is using the gnu-build-system. I guess that means,
> that Guix will go through the usual autotools steps, after extracting a tarball
> or cloning a repository. However, then it would seem, that the success of the
> installation of the package largely hinges on what is defined in the autotools
> related files, like Makefile and such, which are part of the downloaded tar.
Correct. The GNU build system commonly consists of a bootstrap step,
the execution of the configure script, followed by “make” and “make
install”. The gnu-build-system abstraction merely automates that and
assumes that these things exist and are in a functional state, so that
it can call them with certain default arguments.
> Those however, are not described in the cookbook. If one is to create a package,
> which makes use of the gnu-build-system, then a description of how to get this
> done would be good to have. People have done it before, but documentation does
> not capture it.
I can understand the desire for comprehensive documentation, but I think
that’s too far out of scope for even the cookbook. The GNU build system
is just very *very* common, which is why the tutorial uses the
gnu-build-system abstraction. It something you are bound to encounter
when packaging non-trivial C/C++ applications.
Guix has abstractions for many other build systems, such as the
r-build-system, or the cmake-build-system. But I think it would be
excessive to add tutorials on how to write an R package according to
specifications, or how to write CMakeList.txt for a cmake-using project.
> Then there is another confusion: The definition you have written – Is that for
> editing the `guile.scm` in the Guix source tree
Not, for guile.scm but for gnu/packages/guile-xyz.scm or rather the (gnu
package guile-xyz) module. It works in that context because that module
already has all the necessary imports.
--
Ricardo
next prev parent reply other threads:[~2021-04-02 21:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-15 14:46 About packaging documentation Zelphir Kaltstahl
2021-03-15 15:43 ` Ricardo Wurmus
2021-03-16 19:27 ` Zelphir Kaltstahl
2021-03-16 22:03 ` Ricardo Wurmus
2021-03-17 20:43 ` Zelphir Kaltstahl
2021-04-02 11:29 ` Zelphir Kaltstahl
2021-04-02 15:33 ` Zelphir Kaltstahl
2021-04-02 21:59 ` Ricardo Wurmus
2021-04-04 13:41 ` About packaging (was: About packaging documentation) Zelphir Kaltstahl
2021-04-04 14:35 ` Ricardo Wurmus
2021-04-04 15:57 ` Zelphir Kaltstahl
2021-04-04 14:38 ` Tobias Geerinckx-Rice
2021-04-04 15:30 ` Zelphir Kaltstahl
2021-04-02 21:56 ` Ricardo Wurmus [this message]
2021-04-04 13:59 ` About packaging documentation Zelphir Kaltstahl
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=874kgo1hbo.fsf@elephly.net \
--to=rekado@elephly.net \
--cc=help-guix@gnu.org \
--cc=zelphirkaltstahl@posteo.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).