unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* Help making a GNU Guix package for pure GNU Guile library
@ 2021-01-30 17:17 Zelphir Kaltstahl
  2021-01-30 17:55 ` Jérémy Korwin-Zmijowski
                   ` (2 more replies)
  0 siblings, 3 replies; 18+ messages in thread
From: Zelphir Kaltstahl @ 2021-01-30 17:17 UTC (permalink / raw)
  To: Guile User

Hello Guilers!

For some time now I wanted to be able to make Guix package of some of my
Guile projects or at least understand and know how to do that, write a
guide for it and so on, to be able to do it whenever I need it and also
to be able to contribute better to the Guile community and enable others
to read how to create Guile packages and contribute. People would not
have to clone any repo from me directly, but could use Guix to install
stuff.

A few weeks ago I asked in the Guile IRC channel about how to approach
learning the required things. There people recommended me to look at
guile-haunt as an example, because it is also a pure Guile program,
which is packaged for Guix already. So that i what I started doing.

There is a whole jungle of stuff, that I do not yet understand in depth.
Many of those things are GNU Autotools / GNU Automake or GNU M4 related.
I have taken a detailed look at guile-haunt's Makeile.am and documented
anything I understand about it in a plaintext org-mode file. In that
file I wrote "TODO", for example "TODO: explain x" for anything, that I
did not yet understand.

I also have some more general questions, which I want to ask, but first
I want to post the links to what I am referring to:

* guile-haunt repository
Makefile.am: https://github.com/guildhall/guile-haunt/blob/c67e8e924c664ae4035862cc7b439cd7ec4bcef6/Makefile.am

* my own notes about the Makefile.am:
https://notabug.org/ZelphirKaltstahl/guix-package-manager-tutorials/src/01cc6af019862bd6a588c4e376f07bad9f5fb1f3/make-a-package/autotools-usage/guile-haunt.org
(Should I be pasting all the TODO items as separate questions in this
e-mail, or is posting a permalink to the document OK?)

Perhaps you can already see from the TODO things I wrote down there,
that my knowledge about the tooling is quite limited. I've never done a
lot of C programming or other ones, where one often sees Makefiles and
the usual stuff. So if you reply, please keep in mind my beginner
knowledge about these things.

Can you help me out filling the remining gaps in understanding?

Also I have another question, which I will try to answer myself:

Why does guile-haunt use Makefile.am? Why is a simple Makefile not
sufficient?

My own attempt at an answer: Autotools seem to try to be a compatibility
layer for many different systems and perform loads of checks, to
ultimately generate a working Makefile for each system on which the
Makefile.am is processed. This is important for Guix, as Guix is
supposed to work on any GNU/Linux distribution. So by using GNU
Autotools instead of GNU Make directly, I would be making my package
more stable on various systems, on which the defaults may differ from my
own system.

And ultimately: Should I be asking this question on the Guix mailing
list, instead of here?

Best regards,
Zelphir

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




^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Help making a GNU Guix package for pure GNU Guile library
  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 21:15 ` Ricardo Wurmus
  2 siblings, 2 replies; 18+ messages in thread
From: Jérémy Korwin-Zmijowski @ 2021-01-30 17:55 UTC (permalink / raw)
  To: guile-user, Zelphir Kaltstahl, Guile User

Hey Zelphir!

Some years ago I found this blog post https://erikedrosa.com/2017/10/29/guile-projects-with-autotools.html it helped me to experiment a bit.
Then I found Guile-Hall which aims to automate those things.

I'm waiting to see support for guile-build-system in Guile-Hall for example.
I plan to play with it maybe it's not too complicated for me haha.

Cheers,
Jérémy
-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Help making a GNU Guix package for pure GNU Guile library
  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 18:35 ` John Cowan
  2021-01-30 19:43   ` Dr. Arne Babenhauserheide
  2021-01-30 21:15 ` Ricardo Wurmus
  2 siblings, 1 reply; 18+ messages in thread
From: John Cowan @ 2021-01-30 18:35 UTC (permalink / raw)
  To: Zelphir Kaltstahl; +Cc: Guile User

On Sat, Jan 30, 2021 at 12:17 PM Zelphir Kaltstahl <
zelphirkaltstahl@posteo.de> wrote:

There is a whole jungle of stuff, that I do not yet understand in depth.
>

You are not alone.  Warning: completely partisan posting here.

> Why does guile-haunt use Makefile.am? Why is a simple Makefile not
> sufficient?
>

Cargo-cult programming.  Autotools was created in a pre-Posix, pre-ANSI-C
environment that was *much* more diverse than anything today.
Consequently, it makes a whole bunch of unnecessary tests.  What's more,
the generated ./configure file is a great big mess; if it has a bug, you
are pretty much out of luck.

I posted this back in 2012 on another forum:

Chicken, an excellent implementation of Scheme, has a very badass attitude
to configuration, as follows: You tell “make” if you are running on Linux,
BSD, Mac OS X, Solaris, Haiku, Cygwin, MinGW, or MinGW+MSYS, and then a
short platform-specific makefile writes out a little .h file and builds
everything else as-is. If you are *not* running one of those, you’re on
your own — but the community welcomes patches.  [2020 update: You don't
even have to tell it your OS and toolchain any more; it looks at uname(1),
with a hack for MinGW where uname does not exist.]

This is the outcome of many years struggling with autotools, and several
more struggling with CMake. (Chicken compiles Scheme to C and is written in
Scheme, so it has to bootstrap itself, something CMake doesn’t or didn’t
like.)  [Supposedly CMake has fixed this problem now.]

By contrast, I did a bad restore from backup the other day, and Guile
(which uses autotools, small blame to the maintainers — the FSF insists on
it) got confused because I hadn’t restored the file timestamps properly, so
the byte-compiled Scheme looked out of date relative to the source. No
biggie, I just rebuilt Guile from scratch. Ouch. That took longer than it
would have to *re-restore the backup three times over*, and the hard time
was struggling with autotools; I had to run ./configure about twelve times
before it reported all the missing C-level dependencies (not really
missing, just out of date).

[end of quotation]

My own attempt at an answer: Autotools seem to try to be a compatibility
> layer for many different systems


Most of which no longer exist.  Autotools is the complete opposite of
Scheme: it piles feature on top of feature rather than removing the
weaknesses and restrictions that make additional features appear necessary.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
        Is it not written, "That which is written, is written"?


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Help making a GNU Guix package for pure GNU Guile library
  2021-01-30 18:35 ` John Cowan
@ 2021-01-30 19:43   ` Dr. Arne Babenhauserheide
  2021-01-30 20:16     ` divoplade
  0 siblings, 1 reply; 18+ messages in thread
From: Dr. Arne Babenhauserheide @ 2021-01-30 19:43 UTC (permalink / raw)
  To: John Cowan; +Cc: guile-user

[-- Attachment #1: Type: text/plain, Size: 4075 bytes --]


John Cowan <cowan@ccil.org> writes:
> This is the outcome of many years struggling with autotools, and several
> more struggling with CMake. (Chicken compiles Scheme to C and is written in
> Scheme, so it has to bootstrap itself, something CMake doesn’t or didn’t
> like.)  [Supposedly CMake has fixed this problem now.]

In my opinion this in-between-step to CMake is a mistake many made.

I’ve gone through cmake, scons, setuptools, and waf, with a short
involuntary detour to the numpy build system, to end up with autotools,
because all the other tools had a too narrow view of what was necessary
— and when I hit their limits, I was pretty much lost.

Once I actually hacked systemwide installed numpy sources to provide
support for the intel fortran compiler.

Nowadays I experience maven and gradle fail at delivering what autotools
already provide, with IntelliJ filling the gap of incremental rebuilds
by integrating that into the (huge) IDE.

> By contrast, I did a bad restore from backup the other day, and Guile
> (which uses autotools, small blame to the maintainers — the FSF insists on
> it) got confused because I hadn’t restored the file timestamps properly, so
> the byte-compiled Scheme looked out of date relative to the source. No
> biggie, I just rebuilt Guile from scratch. Ouch. That took longer than it
> would have to *re-restore the backup three times over*, and the hard time
> was struggling with autotools; I had to run ./configure about twelve times
> before it reported all the missing C-level dependencies (not really
> missing, just out of date).

Didn’t `make -B` work? Force-rebuild everything.

Seeing that this was 8 years ago: Possibly it didn’t because autotools
didn’t regenerate the configure automatically. It does that nowadays.

> Most of which no longer exist.  Autotools is the complete opposite of
> Scheme: it piles feature on top of feature rather than removing the
> weaknesses and restrictions that make additional features appear necessary.

While autotools does have more features than I personally need, using
autotools replaces many usages of “spin up a whole OS to run a
shell-script” for me. `make distcheck` is what should always be
provided: Create a tarball and ensure that the generated tarball can be
used to build your tool so that the tests pass using a separate
build-directory.

There is some unclean stuff where abstractions got broken (which hurts
me, but then I did not report it as bug yet — that’s on me) but
autotools do actually map the complexity you get in real development. I
personally saw the persumably simpler ways fail in real deployment.

You say that all this complexity does not exist anymore. I’ve
experienced that complexity break every other build tool less than 10
years ago when working on cutting-edge university clusters. Autotools
just worked.

I think configure-runs should be slimmed down by a first check whether
it’s in a known environment (so 90% of the tests can be skipped). But
that’s not a general complaint about the approach of autotools.

And I think that the autotools documentation is still abysmal for
newcomers: There’s no “how to solve this task correctly” for real-life
tasks, and most answers to these questions you find online are wrong, so
most autotools-users actually do resort to cargo-culting (“this worked
in project X”). All the while the world has moved on and most new tools
(like npm, maven, go, cargo, …) auto-generate their (often very complex)
build structures.

I started a project to provide something similar for autotools, but it
still has too little support for different languages:
https://hg.sr.ht/~arnebab/conf “initialize modern autotools projects”

Yet this is where we can actually improve the state of build systems
without failing at the same problems over and over again: Make it easier
to start clean autotools projects.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Help making a GNU Guix package for pure GNU Guile library
  2021-01-30 17:55 ` Jérémy Korwin-Zmijowski
@ 2021-01-30 19:56   ` divoplade
  2021-01-31  3:26   ` Zelphir Kaltstahl
  1 sibling, 0 replies; 18+ messages in thread
From: divoplade @ 2021-01-30 19:56 UTC (permalink / raw)
  To: Jérémy Korwin-Zmijowski, guile-user, Zelphir Kaltstahl

Hello,

Le samedi 30 janvier 2021 à 18:55 +0100, Jérémy Korwin-Zmijowski a
écrit :
> I'm waiting to see support for guile-build-system in Guile-Hall for
> example.

If you use gnu-build-system, you can use a "bootstrap" (or
"autogen.sh") script that will run 'hall dist -x' (with HOME set to a
meaningful directory name, otherwise it won't work in a guix build job)
followed by 'autoreconf -vif'. 

https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/autoreconf-Invocation.html

Best regards




^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Help making a GNU Guix package for pure GNU Guile library
  2021-01-30 19:43   ` Dr. Arne Babenhauserheide
@ 2021-01-30 20:16     ` divoplade
  0 siblings, 0 replies; 18+ messages in thread
From: divoplade @ 2021-01-30 20:16 UTC (permalink / raw)
  To: Dr. Arne Babenhauserheide, John Cowan; +Cc: guile-user

Hello,

Le samedi 30 janvier 2021 à 20:43 +0100, Dr. Arne Babenhauserheide a
écrit :
> I think configure-runs should be slimmed down by a first check
> whether
> it’s in a known environment (so 90% of the tests can be skipped). But
> that’s not a general complaint about the approach of autotools.
The configure script can use a cache file (
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/html_node/Cache-Files.html
), so this can discard some of the tests and speed up things. Since we
are talking about guix (the perfect example of a "known environment",
in my opinion), maybe it could be a feature of guix to generate this
file automatically.




^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Help making a GNU Guix package for pure GNU Guile library
  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 18:35 ` John Cowan
@ 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  3:19   ` Help making a GNU Guix package for pure GNU Guile library Zelphir Kaltstahl
  2 siblings, 2 replies; 18+ messages in thread
From: Ricardo Wurmus @ 2021-01-30 21:15 UTC (permalink / raw)
  To: Zelphir Kaltstahl; +Cc: guile-user


Hi Zelphir,

> For some time now I wanted to be able to make Guix package of some of my
> Guile projects or at least understand and know how to do that, write a
> guide for it and so on, to be able to do it whenever I need it and also
> to be able to contribute better to the Guile community and enable others
> to read how to create Guile packages and contribute. People would not
> have to clone any repo from me directly, but could use Guix to install
> stuff.

There is a packaging tutorial in the Guix Cookbook:

    https://guix.gnu.org/cookbook/en/html_node/Packaging.html

> A few weeks ago I asked in the Guile IRC channel about how to approach
> learning the required things. There people recommended me to look at
> guile-haunt as an example, because it is also a pure Guile program,
> which is packaged for Guix already. So that i what I started doing.
>
> There is a whole jungle of stuff, that I do not yet understand in depth.
> Many of those things are GNU Autotools / GNU Automake or GNU M4
> related. […]

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).

-- 
Ricardo



^ permalink raw reply	[flat|nested] 18+ messages in thread

* build system for pure Guile library (was Re: Help making a GNU Guix package for pure GNU Guile library)
  2021-01-30 21:15 ` Ricardo Wurmus
@ 2021-01-31  0:26   ` pelzflorian (Florian Pelz)
  2021-01-31  6:29     ` Ricardo Wurmus
  2021-01-31  3:19   ` Help making a GNU Guix package for pure GNU Guile library Zelphir Kaltstahl
  1 sibling, 1 reply; 18+ messages in thread
From: pelzflorian (Florian Pelz) @ 2021-01-31  0:26 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guile-user

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.  This is no
problem for guile-srfi-89’s single Scheme file, but I think larger
Guile-only projects (including libraries) should still use make.  Am I
wrong?

Regards,
Florian



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Help making a GNU Guix package for pure GNU Guile library
  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  3:19   ` Zelphir Kaltstahl
  2021-02-03 18:43     ` Adriano Peluso
  1 sibling, 1 reply; 18+ messages in thread
From: Zelphir Kaltstahl @ 2021-01-31  3:19 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guile-user

Hello Ricardo!

At first I thought "How could I overlook that guide?", but then I
realized it is the one I tried following before. This fails for my
library at the `guix package --install-from-file=my-hello.scm` step and
I seem to not be able to get it to work. Perhaps it is something simple.

I have the state of what I tried at (permalink)
https://notabug.org/ZelphirKaltstahl/guix-package-manager-tutorials/src/85bd80735b44ac0bab5f1565e6c5ce1defdf7ef9/make-a-package
and there is a `package.scm` file, which I try with `guix package
--install-from-file='package.scm'`.

Should I move this over to the Guix list? On one hand it is about a
Guile library, so it would be good to have the knowledge here, but on
the other hand it is mainly about what to do for packaging.

In general, I would like to go the simplest and cleanest way to make a
package. Perhaps I will need more at some point, if I write a program,
that is not pure Guile, but I have not yet planned any such project.
Perhaps for making packages for other programming languages, when those
packages are not yet in Guix.

Best regards,
Zelphir

On 1/30/21 10:15 PM, Ricardo Wurmus wrote:
> Hi Zelphir,
>
>> For some time now I wanted to be able to make Guix package of some of my
>> Guile projects or at least understand and know how to do that, write a
>> guide for it and so on, to be able to do it whenever I need it and also
>> to be able to contribute better to the Guile community and enable others
>> to read how to create Guile packages and contribute. People would not
>> have to clone any repo from me directly, but could use Guix to install
>> stuff.
> There is a packaging tutorial in the Guix Cookbook:
>
>     https://guix.gnu.org/cookbook/en/html_node/Packaging.html
>
>> A few weeks ago I asked in the Guile IRC channel about how to approach
>> learning the required things. There people recommended me to look at
>> guile-haunt as an example, because it is also a pure Guile program,
>> which is packaged for Guix already. So that i what I started doing.
>>
>> There is a whole jungle of stuff, that I do not yet understand in depth.
>> Many of those things are GNU Autotools / GNU Automake or GNU M4
>> related. […]
> 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).
>
-- 
repositories: https://notabug.org/ZelphirKaltstahl




^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Help making a GNU Guix package for pure GNU Guile library
  2021-01-30 17:55 ` Jérémy Korwin-Zmijowski
  2021-01-30 19:56   ` divoplade
@ 2021-01-31  3:26   ` Zelphir Kaltstahl
  1 sibling, 0 replies; 18+ messages in thread
From: Zelphir Kaltstahl @ 2021-01-31  3:26 UTC (permalink / raw)
  To: Jérémy Korwin-Zmijowski, guile-user

Thank you Jérémy! This looks interesting and just like what I was
looking for, in case I have to use Autotools. Even if it turns out that
I do not have to use them and can go a simpler route, it still seems
like a good resource for getting to know that stuff more.

Best regards,
Zelphir

On 1/30/21 6:55 PM, Jérémy Korwin-Zmijowski wrote:
> Hey Zelphir!
>
> Some years ago I found this blog post
> https://erikedrosa.com/2017/10/29/guile-projects-with-autotools.html
> it helped me to experiment a bit.
> Then I found Guile-Hall which aims to automate those things.
>
> I'm waiting to see support for guile-build-system in Guile-Hall for
> example.
> I plan to play with it maybe it's not too complicated for me haha.
>
> Cheers,
> Jérémy
> -- 
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez
> excuser ma brièveté. 

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




^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: build system for pure Guile library (was Re: Help making a GNU Guix package for pure GNU Guile library)
  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
  0 siblings, 1 reply; 18+ messages in thread
From: Ricardo Wurmus @ 2021-01-31  6:29 UTC (permalink / raw)
  To: pelzflorian (Florian Pelz); +Cc: guile-user


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.

-- 
Ricardo



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: build system for pure Guile library (was Re: Help making a GNU Guix package for pure GNU Guile library)
  2021-01-31  6:29     ` Ricardo Wurmus
@ 2021-01-31 14:16       ` Zelphir Kaltstahl
  2021-01-31 15:38         ` Dr. Arne Babenhauserheide
  2021-02-03 18:31         ` Adriano Peluso
  0 siblings, 2 replies; 18+ messages in thread
From: Zelphir Kaltstahl @ 2021-01-31 14:16 UTC (permalink / raw)
  To: Ricardo Wurmus, pelzflorian (Florian Pelz); +Cc: guile-user

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




^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: build system for pure Guile library (was Re: Help making a GNU Guix package for pure GNU Guile library)
  2021-01-31 14:16       ` Zelphir Kaltstahl
@ 2021-01-31 15:38         ` Dr. Arne Babenhauserheide
  2021-02-03 23:07           ` Zelphir Kaltstahl
  2021-02-03 18:31         ` Adriano Peluso
  1 sibling, 1 reply; 18+ messages in thread
From: Dr. Arne Babenhauserheide @ 2021-01-31 15:38 UTC (permalink / raw)
  To: Zelphir Kaltstahl; +Cc: guile-user

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]


Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes:
> 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

Here are three reasons for building of a pure-guile ication:

- avoid the initial start time due to auto-compilation
- set specific optimization parameters (i.e. O3)
- bake-in system-specific data-paths (i.e. images to load)

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: build system for pure Guile library (was Re: Help making a GNU Guix package for pure GNU Guile library)
  2021-01-31 14:16       ` Zelphir Kaltstahl
  2021-01-31 15:38         ` Dr. Arne Babenhauserheide
@ 2021-02-03 18:31         ` Adriano Peluso
  1 sibling, 0 replies; 18+ messages in thread
From: Adriano Peluso @ 2021-02-03 18:31 UTC (permalink / raw)
  To: Zelphir Kaltstahl; +Cc: guile-user

Il giorno dom, 31/01/2021 alle 15.16 +0100, Zelphir Kaltstahl ha
scritto:
> 
> 
> 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.

One good reason could be that your Guile based project wraps some C
library, like guile-git

In that case, if you want to support shipping your project to non guix
platforms, the services of autoconf (for testing if the C library is
available on that platform, in which version, if it has this and that
functionality) could be useful

And this goes not only with wrapping C libraries but also with
extensions


If your project doesn't deal with any C code, the reason to use the
autotools is for installing it in a way that it's available to all the
users on a Unix machine

And finally, it could help distributions in packaging it

These 2 points could be true for the Guile build system too, I don't
know

Hope this helps





^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Help making a GNU Guix package for pure GNU Guile library
  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
  0 siblings, 1 reply; 18+ messages in thread
From: Adriano Peluso @ 2021-02-03 18:43 UTC (permalink / raw)
  To: Zelphir Kaltstahl; +Cc: guile-user

Il giorno dom, 31/01/2021 alle 04.19 +0100, Zelphir Kaltstahl ha
scritto:
> Hello Ricardo!
> 
> At first I thought "How could I overlook that guide?", but then I
> realized it is the one I tried following before. This fails for my
> library at the `guix package --install-from-file=my-hello.scm` step
> and
> I seem to not be able to get it to work. Perhaps it is something
> simple.
> 
> I have the state of what I tried at (permalink)
> https://notabug.org/ZelphirKaltstahl/guix-package-manager-tutorials/src/85bd80735b44ac0bab5f1565e6c5ce1defdf7ef9/make-a-package
> and there is a `package.scm` file, which I try with `guix package
> --install-from-file='package.scm'`.


If I was in your shoes, I'd use guile-hall

guile-hall uses tha autotools but in an automated way, you don't have
to deal with them yourself

Also, it ships your package with a guix.scm file so you don't have to
write it yourself




^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: build system for pure Guile library (was Re: Help making a GNU Guix package for pure GNU Guile library)
  2021-01-31 15:38         ` Dr. Arne Babenhauserheide
@ 2021-02-03 23:07           ` Zelphir Kaltstahl
  2021-02-04  0:09             ` Ricardo Wurmus
  0 siblings, 1 reply; 18+ messages in thread
From: Zelphir Kaltstahl @ 2021-02-03 23:07 UTC (permalink / raw)
  To: Dr. Arne Babenhauserheide; +Cc: guile-user

Hello Arne!

Thank you for that! Do you have an example for when one would bake in
system-specific data-paths?

Best wishes,
Zelphir

On 1/31/21 4:38 PM, Dr. Arne Babenhauserheide wrote:
> Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes:
>> 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
> Here are three reasons for building of a pure-guile ication:
>
> - avoid the initial start time due to auto-compilation
> - set specific optimization parameters (i.e. O3)
> - bake-in system-specific data-paths (i.e. images to load)
>
> Best wishes,
> Arne

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




^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: Help making a GNU Guix package for pure GNU Guile library
  2021-02-03 18:43     ` Adriano Peluso
@ 2021-02-03 23:12       ` Zelphir Kaltstahl
  0 siblings, 0 replies; 18+ messages in thread
From: Zelphir Kaltstahl @ 2021-02-03 23:12 UTC (permalink / raw)
  To: randomlooser; +Cc: guile-user

Hi Adriano,

Thank you also for the information in your other reponse. I'll take
another look at guile-hall.

Regards,
Zelphir

On 2/3/21 7:43 PM, Adriano Peluso wrote:
> Il giorno dom, 31/01/2021 alle 04.19 +0100, Zelphir Kaltstahl ha
> scritto:
>> Hello Ricardo!
>>
>> At first I thought "How could I overlook that guide?", but then I
>> realized it is the one I tried following before. This fails for my
>> library at the `guix package --install-from-file=my-hello.scm` step
>> and
>> I seem to not be able to get it to work. Perhaps it is something
>> simple.
>>
>> I have the state of what I tried at (permalink)
>> https://notabug.org/ZelphirKaltstahl/guix-package-manager-tutorials/src/85bd80735b44ac0bab5f1565e6c5ce1defdf7ef9/make-a-package
>> and there is a `package.scm` file, which I try with `guix package
>> --install-from-file='package.scm'`.
>
> If I was in your shoes, I'd use guile-hall
>
> guile-hall uses tha autotools but in an automated way, you don't have
> to deal with them yourself
>
> Also, it ships your package with a guix.scm file so you don't have to
> write it yourself
>
-- 
repositories: https://notabug.org/ZelphirKaltstahl




^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: build system for pure Guile library (was Re: Help making a GNU Guix package for pure GNU Guile library)
  2021-02-03 23:07           ` Zelphir Kaltstahl
@ 2021-02-04  0:09             ` Ricardo Wurmus
  0 siblings, 0 replies; 18+ messages in thread
From: Ricardo Wurmus @ 2021-02-04  0:09 UTC (permalink / raw)
  To: Zelphir Kaltstahl; +Cc: guile-user


Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes:

> Do you have an example for when one would bake in
> system-specific data-paths?

To satisfy distribution packaging standards your project files may end
up in different directories and cannot assume that the relative relationship
between files remains unchanged.  So if you include images, for example,
and your code loads them then your code cannot assume that they are both
in the same directory.

Your compiled code may end up in a sub-directory of
${prefix}/lib/guile/3.0/site-ccache while your image data might end up
in ${prefix}/share/${application_name}/images.  Or it could be something
completely different.  Conventional “configure” scripts (as generated by
autoconf) give the user the ability to overwrite default locations by
passing “--prefix”, “--localstatedir”, “--libdir”, “--datadir”,
“--datarootdir”, etc.

The fewer assumptions your code makes about locations the happier the
distro packagers will be.  Autoconf and Automake let you record
configured locations by replacing @placeholders@ in template files
ending on “.in”.  Often you’d have a config.scm.in that contains
references to these placeholders and is converted to config.scm during
the run of the “configure” script.

-- 
Ricardo



^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2021-02-04  0:09 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

unofficial mirror of guile-user@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guile-user/0 guile-user/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guile-user guile-user/ https://yhetil.org/guile-user \
		guile-user@gnu.org
	public-inbox-index guile-user

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.lisp.guile.user
	nntp://news.gmane.io/gmane.lisp.guile.user


AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git