unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
To: Ricardo Wurmus <rekado@elephly.net>,
	"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de>
Cc: guile-user@gnu.org
Subject: Re: build system for pure Guile library (was Re: Help making a GNU Guix package for pure GNU Guile library)
Date: Sun, 31 Jan 2021 15:16:52 +0100	[thread overview]
Message-ID: <f72f1bd3-f5c8-d92c-a435-ef7a94610984@posteo.de> (raw)
In-Reply-To: <87mtwphb63.fsf@elephly.net>

This may be short sighted or uninformed, but generally I don't know, why
I would build anything, except for running it. If I am not confused
about the terminology, then I would say a pure Guile library is built,
when I run the Guile program that makes use of the library. Perhaps also
before that, so that the program starts up quickly, when run the first
time. That is, if it is still only in source code form and has not been
compiled before. Perhaps that is a reason for "building"?

I did not really distinguish building and packaging before asking the
original questions on the mailing list, because I assumed, that I would
have to go through the whole autotools stuff, to actually make a Guix
package, just like it is done in the guile-haunt repository.

Apparently it is not the case, that I need to go through the autotools
stuff for a pure Guile library, if I can get the approach from the Guix
cookbook working, which I however, have not yet managed to do.

I don't know what other use-cases there are for building, except for
running the code. Perhaps distributing with something like Debian
packages? I've never packaged a software in a Debian package either. The
whole packaging is still sort of new territory and I would like to keep
it very simple.

If I had my library as a Guix package, it would also simplify my own
repositories, because I could simply write the name in the manifest for
the environment and would not need to clone it as a git submodule to get
my code working, which relies on the library.

However, if anyone told me a good reason to also use autotools to manage
a build process of my code, and I can get it working and understand how
to do it, then why not.


On 1/31/21 7:29 AM, Ricardo Wurmus wrote:
> pelzflorian (Florian Pelz) <pelzflorian@pelzflorian.de> writes:
>
>> Hi Ricardo,
>>
>> On Sat, Jan 30, 2021 at 10:15:20PM +0100, Ricardo Wurmus wrote:
>>> If all you have are Guile modules and all you want is to package it for
>>> Guix then you really don’t need to bother with Autotools.  Use the
>>> “guile-build-system”.  It can be as simple as the “guile-srfi-89”
>>> package in (gnu packages guile-xyz).
>> But using Guix instead of a Makefile for building means *all* .scm
>> files would need to be recompiled with each change.
> If this is only about *packaging for Guix* it makes no difference because
> Guix builds everything from source anyway.
>
> The goal here is not to replace a build system with Guix.
>
-- 
repositories: https://notabug.org/ZelphirKaltstahl




  reply	other threads:[~2021-01-31 14:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-30 17:17 Help making a GNU Guix package for pure GNU Guile library Zelphir Kaltstahl
2021-01-30 17:55 ` Jérémy Korwin-Zmijowski
2021-01-30 19:56   ` divoplade
2021-01-31  3:26   ` Zelphir Kaltstahl
2021-01-30 18:35 ` John Cowan
2021-01-30 19:43   ` Dr. Arne Babenhauserheide
2021-01-30 20:16     ` divoplade
2021-01-30 21:15 ` Ricardo Wurmus
2021-01-31  0:26   ` build system for pure Guile library (was Re: Help making a GNU Guix package for pure GNU Guile library) pelzflorian (Florian Pelz)
2021-01-31  6:29     ` Ricardo Wurmus
2021-01-31 14:16       ` Zelphir Kaltstahl [this message]
2021-01-31 15:38         ` Dr. Arne Babenhauserheide
2021-02-03 23:07           ` Zelphir Kaltstahl
2021-02-04  0:09             ` Ricardo Wurmus
2021-02-03 18:31         ` Adriano Peluso
2021-01-31  3:19   ` Help making a GNU Guix package for pure GNU Guile library Zelphir Kaltstahl
2021-02-03 18:43     ` Adriano Peluso
2021-02-03 23:12       ` 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://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f72f1bd3-f5c8-d92c-a435-ef7a94610984@posteo.de \
    --to=zelphirkaltstahl@posteo.de \
    --cc=guile-user@gnu.org \
    --cc=pelzflorian@pelzflorian.de \
    --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).