[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Newbie thoughts on Guile Hall + Guix

From: adriano
Subject: Re: Newbie thoughts on Guile Hall + Guix
Date: Mon, 07 Feb 2022 23:35:09 +0100

Il giorno dom, 06/02/2022 alle 21.34 +0000, Zelphir Kaltstahl ha
> On 2/6/22 16:29, Vijay Marupudi wrote:
> > Ognen Duzlevski <> writes:
> > 
> > > Have you tried Racket? If you haven't - try that and you will
> > > find
> > > recommending Guile to beginners to be much easier ;). On a
> > > serious note,
> > > there are other schemes that have their own package managers
> > > (e.g.
> > > Racket).
> > I have, but I like Guile better, and want everyone to use it :) I
> > think
> > being an extension language is a very useful and important part of
> > what
> > makes Guile great.
> > 
> > > IMHO, this learning curve is a part of learning any language. The
> > > reason
> > > why every language comes with a language "specific" manager is
> > > because a
> > > lot of people have tried to solve this problem and failed to find
> > > the
> > > magic bullet. At some level you are relying on the language's
> > > portability itself, then on the same level you are wanting to
> > > exploit
> > > some of the language's specifics, then on the same level someone
> > > comes
> > > along and says for some packages this approach doesn't work... ;)
> > I don't think it's fair to say that using packages in Guile just as
> > easy/hard as other languages. Python / Javascript make this
> > incredibly
> > easy, and their ecosystem is evidence for that success. Their
> > package
> > managers have flaws, but they have benefits too, and those benefits
> > would be great for Guile.
> > 
> > Note that I'm not saying that this package manager has to do
> > everything
> > expected of a battle-tested production package manager. Just make
> > it
> > easier for beginners to use and make packages (which will be Guix
> > compatible by default). And we should not underestimate what
> > beginners
> > can do for a language. They might be new to Guile, but possess a
> > lot of
> > other traits that would be great, like domain expertise in science,
> > writing skills, etc. which would be great for the ecosystem.
> > 
> > Advanced users can use Guix or do the ./configure && make && make
> > install dance.
> I find using Guix to be much better than the ./configure && make &&
> make stuff. 
> The reason is, that I always think: "What, if it doesn't work and I
> want to 
> clean up my system afterwards?". I can't stand it, if any remains of
> non-working 
> stuff is left on the system.
> I am fine with using Guix. I like Guix. It is just that making a
> package is way 
> to hard for newcomers. I needed weeks to make one simple pure Guile
> package, 
> because I burned out trying to do it and had to have pauses in
> between, before I 
> could muster new energy to try again. That still haunts me, so that I
> still have 
> not updated my package, even though I have a newer release for months
> by now. 
> Especially the whole (in the end unnecessary) autotools stuff was
> exhausting. 
> Trying to understand what all those files do in my package. It is
> sort of my own 
> problem, because I cannot leave it alone and just be done with it. I
> want to 
> understand it. 

Just don't

That stuff is too low level for human beings

The only autotools files you should care about are the ones meant to be
written by a human being (the package author)

The ones it produces in its own are not meant to be "understood"

With Guile-Hall you don't even need to understand the autotools files
meant to be edited by human beings

Becaue Hall will edit those for you


The essential part is short and it's as follows

There are 2 people in ths scenario: you (the package author) and
someone who downloads your package and runs configure; make

The autoconf file you (the package author) edit is meant to produce a
bash script 

Such bash file is called "configure" (it will be called by the user of
your package)

and it does 2 things:

1) checks features available on the system of the user running
configure; make

2) based on the results of the checks (and also based on another file),
writes a makefile that will pilot the building

So now you can call make and make will execute the makefile written

That's all

Now: Guix leverages this machinery to manage your package

Because of that, defining an autotools based package for Guix is easier
than it is to configure a package that has no build system

because if your package has no build system, the building process will
have to be expressed in Guix code

If, instead, it has a build system (the autotools or any other) Guix
will charge the build system with the building process, maybe calling
its APIs, so the definition can be more streamlined

Anyway, I feel your frustration, I've been there myself

Actually I've been there with Guile more than with Guix

But still I feel you

I hope this message of mine can sooth your frustration, to some extent

reply via email to

[Prev in Thread] Current Thread [Next in Thread]