[Top][All Lists]

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

Re: Newbie thoughts on Guile Hall + Guix

From: Olivier Dion
Subject: Re: Newbie thoughts on Guile Hall + Guix
Date: Sun, 06 Feb 2022 18:00:44 -0500

On Sun, 06 Feb 2022, Maxime Devos <> wrote:
> Olivier Dion schreef op zo 06-02-2022 om 17:05 [-0500]:
>> > Is it restricted to Makefiles, or can it also be used without
>> > generating Makefiles?  If not, things like progress bars should be
>> > easy
>> > to implement and file names containing spaces or ‘special
>> > characters’
>> > can be used without any problems.
>> Since it's glued to my project, and since I'm very familiar with
>> Makefiles, it only support Makefiles for now.  What would be the
>> other
>> targets you have in mind?
> I was thinking of something like
> $ cd ~/the-source-code
> # (I haven't looked much yet, possibly the CLI needs to be very
> different)
> $ cbuild make --target=aarch64-linux-gnu --prefix=/foo/bar
> $ cbuild install --staged-install=/blah

I'm not a fan of configuration with CLI like `--prefix`.  I like to have
a configuration file that is configurable like so:

'((TARGET . aarch64)
  (PREFIX . /foor/bar))

> Basically, don't delegate to 'make' or 'ninja' or whatever, just build
> it.

I agree.  In the end `make` is only there for tracking dependencies,
which can be done easily in Guile I guess.  Although, there might be
performance problems at large scale, but I don't think I'm there yet ;-)

> That's way less portable than 'make' of course, but people that don't
> have 'cbuild' or don't want to learn 'cbuild' can still use the
> Makefile.

Across distros or OS?  For other distros, if the only requirements are
Guile and pkg-config then I would say that's quite portabled.  As for
other OS, I personnaly don't care about them.

> I noted that you are using #nil in some places.
> #nil (an amalgation of #false and the empty list ()) is mostly an
> implementation detail for Emacs Lisp support, and not something that
> needs to be used in pure Guile.  I would use '() instead; it's
> also more portable to other Schemes.

I did not know that '() was more portable!  I did find out that #nil has
some problem during syntaxes expansion though.  I will change this in my

> There's also some potential reproducibility problems: in
> D1CACHE_LINE_SIZE is set based on the cache size where it was
> compiled, instead of the cache size where it is supposed to run on.

This is true.  Fortunately, on a good amount of architectures, L1 cache
is 64 bytes.  The only way I can see to fix this is to override the
configuration in `.config.scm` if compiling for another system.  It's
not possible to do this at runtime, because I use it for some struct
alignments of static variables.

Olivier Dion

reply via email to

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