unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: help-guix@gnu.org
Subject: Re: About packaging documentation
Date: Sun, 4 Apr 2021 15:59:51 +0200	[thread overview]
Message-ID: <7cbb6849-f035-ee11-9e69-19ab0829ade2@posteo.de> (raw)
In-Reply-To: <874kgo1hbo.fsf@elephly.net>

On 4/2/21 11:56 PM, Ricardo Wurmus wrote:
> 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.
I shall share my notes, if I get it working reproducibly. Until then, I am
maintaining notes at
https://notabug.org/ZelphirKaltstahl/gnu-guile-gnu-guix-packaging-guide
<https://notabug.org/ZelphirKaltstahl/gnu-guile-gnu-guix-packaging-guide>.
>> (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.

Ah, OK.

Best regards,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl



      reply	other threads:[~2021-04-04 14:00 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         ` About packaging documentation Ricardo Wurmus
2021-04-04 13:59           ` Zelphir Kaltstahl [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

  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=7cbb6849-f035-ee11-9e69-19ab0829ade2@posteo.de \
    --to=zelphirkaltstahl@posteo.de \
    --cc=help-guix@gnu.org \
    --cc=rekado@elephly.net \
    /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).