[bug#55606,2/2] gnu: Add hare.

* gnu/packages/hare.scm (hare): New variable.
---
Guix style was indenting badly when applied to the hare package, putting the
text far past 80 characters. Corrected it by hand.

 gnu/packages/hare.scm | 136 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 136 insertions(+)
 create mode 100644 gnu/packages/hare.scm

Antero Mejr via Guix-patches via schreef op ma 23-05-2022 om 21:21 [-
0400]:
> +      (arguments
> +       `(#:tests? #f ;no test suite
> +         #:make-flags
> +         (list (string-append "CC="
> +                              ,(cc-for-target))
> +               (string-append "DESTDIR="
> +                              (assoc-ref %outputs "out")) "PREFIX=")
> +         #:phases
> +         (modify-phases %standard-phases
> +           (replace 'configure
> +             (lambda* (#:key configure-flags #:allow-other-keys)
> +               (setenv "QBE"
> +                       (string-append (assoc-ref %build-inputs "qbe")
> +                                      "/bin/qbe"))
> +               ;; configure rejects unrecognized options
> +               (apply invoke "./configure" configure-flags))))))

input labels can be eliminated (see
<https://guix.gnu.org/en/blog/2021/the-big-change/>):

  (arguments
    (list ...
          #:phases
          #~(modify-phases ...
               (setenv "QBE" (which "qbe"))
               (apply invoke ...))))

Also, 'qbe' looks like a non-native input input, IIUC that 'harec'
invokes 'qbe' under the hood.  (in that case, use (search-input-file
inputs "/bin/qbe") instead). As a test, you can do "guix build harec"
and "guix gc --refences /gnu/store/HAS-harec-VERSION" to see if it ends
up in the references.

Greetings,
Maxime.

Antero Mejr via Guix-patches via schreef op ma 23-05-2022 om 21:21 [-
0400]:
> +       `(#:make-flags
> +         (list (string-append "DESTDIR=" (assoc-ref %outputs "out"))
> +               "BINDIR=/bin"
> +               "MANDIR=/share/man"
> +               "SRCDIR=/src"
> +               "LOCALSRCDIR=/src/hare"

See previous message about G-exp and DESTDIR.

+               (string-append "HAREPATH="
+                              (assoc-ref %outputs "out")
+                              "/src/hare/stdlib:"
+                              (assoc-ref %outputs "out")

Likewise, (assoc-ref ... "out") -> #$output


+               (string-append "HAREC="
+                              (string-append (assoc-ref %build-inputs
"harec")
+                                             "/bin/harec"))

Likewise about input labels, though in this case search-input-file.
Or (file-append #$(this-package-input "harec") "/bin/harec").

+               (string-append "AS="
+                              (string-append (assoc-ref %build-inputs
"binutils")

IIRC %build-inputs does not exist when cross-compiling, try "guix build
--target=aarch64-linux-gnu hare".  Also, it is ambigious if you meant
inputs or native-inptus here.  You might need %build-target-input or
one of those instead.  They are undocumented though, so maybe better
use this-package-{native,}-input.  Those don't support implicit inputs
though, so you may need to add the gcc manually (maybe look at (guix
build-system gnu) for how).

> +               "HARECACHE=.cache")

Is this used for building the hare compiler itself or for building hare
libraries and applications?

Greetings,
Maxime.

Antero Mejr via Guix-patches via schreef op ma 23-05-2022 om 21:21 [-
0400]:
> +               (string-append "LD="
> +                              (string-append (assoc-ref %build-inputs "binutils")

Looking at the makefile, I think all you need is "LD=ld".  Or maybe
"LD=TARGET-ld".

Antero Mejr via Guix-patches via 写道：
> Guix style was indenting badly when applied to the hare package, 
> putting the
> text far past 80 characters. Corrected it by hand.

This caught my attention; I didn't review anything.

Guix style just follows the same rules we should follow.  Don't 
‘fix’ the result unless there's a real bug in ‘guix style’.

Instead, work with it, in this case by adding newlines.  This:

  (proc "foo"
   "bar")

reads *wrong* to humans.

Worse, it's forever a pain to maintain, because nobody can ever 
auto-indent any changes they make to your hand-tweaked code.  They 
have to work around it.

Instead, when necessary, write:

  (proc
   "foo"
   "bar")

> +         (list (string-append "DESTDIR=" (assoc-ref %outputs 
> "out"))

In this case you'd a newline after the above ‘string-append’.

> +               (string-append "HAREC="
> +                              (string-append (assoc-ref 
> %build-inputs "harec")
> +                                             "/bin/harec"))

This is easy to fix: theres no need for the inner string-appends 
in this section.

  (string-append "HAREC="
                 (assoc-ref %build-inputs "harec")
                 "/bin/harec")

is 100% equivalent.  If the line is still too long, add newlines 
where it keeps the code the clearest.

With such changes, you can run ‘guix style’ (or let your editor 
indent the code) without worries or manual fix-ups.

Kind regards,

T G-R

Thanks for the suggestions Maxime and Tobias, the patch above uses the new gexps and has better styling. The new patch was tested by building the hare programs 'hautils', which compiled and ran successfully.

Maxime, the HARECACHE directory is a temporary build directory for the compiler itself, yes.

Please let me know if there are any futher issues.

Am Freitag, dem 03.06.2022 um 13:54 -0400 schrieb Antero Mejr:
> Please let me know if there are any futher issues.
For what it's worth, the patch should probably be split in three (one
for as-for-target, one for harec, one for hare).

Maxime, Tobias, what else is missing?

FYI, I added Hare packages and libraries to Guix 'R Us a while ago, but
was waiting for 1.0 to send it here:

https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/hare.scm
https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/common/hare.scm

    -- (

Some notes:

+ `hare` is not a compiler for Hare, it's a build tool. (It's going to
  include a self-hosted compiler eventually though :))
+ I think the way this patch handles config.mk from `hare` is better.
+ The Guix 'R Us version works with cross-compilation; I don't think this
  one does?
+ harec and qbe probably shouldn't be propagated; their paths should be
  patched into the source code.

    -- (

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> For what it's worth, the patch should probably be split in three (one
> for as-for-target, one for harec, one for hare).

I split out as-for-target into a new patch/issue #56224, since it does
not directly involve hare:
https://issues.guix.gnu.org/56224

Hi (,

"(" <paren@disroot.org> writes:
> Some notes:
>
> + `hare` is not a compiler for Hare, it's a build tool. (It's going to
>   include a self-hosted compiler eventually though :))

The above 2 patches are a combination of your guixrus patches and mine.
The descriptions are replaced with your better ones, and you are
credited at the top.

> + I think the way this patch handles config.mk from `hare` is better.

I kept that part in the new patches.

> + The Guix 'R Us version works with cross-compilation; I don't think this
>   one does?
You mean cross-compilation of hare code? When I try to use hare build -t
(the target flag) it gives me a not implemented error, so I don't think
hare cross-compilation is possible right now.

As for cross-compilation of the guix hare build, I think the
platform-linux-architecture bit should take care of it, right?

> + harec and qbe probably shouldn't be propagated; their paths should be
>   patched into the source code.
>
>     -- (

I'm unsure about this one - maybe the user would want to use harec or
qbe by themselves to debug a build step?
I wanted to give the user a full hare build environment when
they run `guix install hare`, but I understand your logic for wanting to
patch the paths in.

Thanks,
Antero

"(" <paren@disroot.org> writes:

> FYI, I added Hare packages and libraries to Guix 'R Us a while ago, but
> was waiting for 1.0 to send it here:
>

Hare is already in Nixpkgs and AUR, so I think it would be good to make
the language available in Guix. I haven't seen a release plan, so
1.0.0 could still be far off.

Antero Mejr schreef op zo 26-06-2022 om 00:40 [-0400]:
> > + The Guix 'R Us version works with cross-compilation; I don't
> > think this
> >    one does?
> You mean cross-compilation of hare code? When I try to use hare build
> -t (the target flag) it gives me a not implemented error, so I don't
> think hare cross-compilation is possible right now.

IIRC, it was for cross-compiling the compiler itself, not using harec
as a cross-compiler.

Greetings,
Maxime.

Antero Mejr schreef op zo 26-06-2022 om 00:40 [-0400]:
> > + harec and qbe probably shouldn't be propagated; their paths
> > should be
> >    patched into the source code.
> > 
> >      -- (
> 
> I'm unsure about this one - maybe the user would want to use harec or
> qbe by themselves to debug a build step?

FWIW, they can use "guix install harec qbe" for that.

Greetings,
Maxime.

On Sun Jun 26, 2022 at 5:40 AM BST, Antero Mejr wrote:
> As for cross-compilation of the guix hare build, I think the
> platform-linux-architecture bit should take care of it, right?

My mistake, I realized that it would work shortly after sending that.

> I'm unsure about this one - maybe the user would want to use harec or
> qbe by themselves to debug a build step?
> I wanted to give the user a full hare build environment when
> they run `guix install hare`, but I understand your logic for wanting to
> patch the paths in.

There are a few compilers where intermediate build programs aren't
included in propagated-inputs:

+ neither ldc nor zig include ld or as (nor the llvm equivalents)
+ neither nim nor ghc include gcc

I think it should be fine.

    -- (

"(" <paren@disroot.org> writes:

> There are a few compilers where intermediate build programs aren't
> included in propagated-inputs:
>
> + neither ldc nor zig include ld or as (nor the llvm equivalents)
> + neither nim nor ghc include gcc
>
> I think it should be fine.

If harec/qbe are not installed, hare raises an error saying that it
cannot find the program, so users will know to install it. So yes it
should be fine, I moved those programs into native-inputs.

If we moved qbe/harec to inputs, we could patch os::tryenv in
schedule.ha to resolve to the guix path. That way the user gets a
working toolchain by default, but they could still swap in different
versions of qbe/harec using the QBE/HAREC environment variables.
Let me know if that would be preferred over leaving qbe/harec in
native-inputs.

Thanks,
Antero

Antero Mejr schreef op zo 26-06-2022 om 10:07 [-0400]:
> If harec/qbe are not installed, hare raises an error saying that it
> cannot find the program, so users will know to install it. So yes it
> should be fine,
> 

TBC: what is this package packaging?

  * the compiler
  * some wrapper around the compiler
  * the standard library and the compiler
  * both

If it packages the compiler, this is not fine.  Guix is a package
manager and distribution, the point of which is to automatically sort
out dependencies.  Leaving it up to the user to sort out the
dependencies then partially defeats the point.

Greetings,
Maxime.

Maxime Devos <maximedevos@telenet.be> writes:

> TBC: what is this package packaging?
>
>   * the compiler
>   * some wrapper around the compiler
>   * the standard library and the compiler
>   * both
>
> If it packages the compiler, this is not fine.  Guix is a package
> manager and distribution, the point of which is to automatically sort
> out dependencies.  Leaving it up to the user to sort out the
> dependencies then partially defeats the point.

My current understanding is:
The "hare" package is the standard library and a "build driver", which
orchestrates the program "harec" to compile hare programs into QBE IR,
and then hare calls qbe and binutils to compile the program to a
binary.

I think they refer to a "build driver" as "a program that calls other
programs to do a build". Kind of like Rust's cargo build system,
but without full package management.

However, in the future the plan is for hare to be a self-hosted
compiler and build system, dropping the harec dependency (will still
need it, but just for bootstrapping). Not sure if they will replace qbe
as well.

Our options are:
1. Provide the build driver "hare" standalone, then a "hare-toolchain"
package that propagates hare, harec, qbe, and binutils. This is how it
was done by ) on Guix'R'Us.
2. Add qbe and harec to propagated-inputs of hare. This is what the
earlier patch did.
3. Add qbe and harec to inputs, and patch the source code to direct
the build driver to the Guix paths.

On Sun Jun 26, 2022 at 3:07 PM BST, Antero Mejr wrote:
> If we moved qbe/harec to inputs, we could patch os::tryenv in
> schedule.ha to resolve to the guix path. That way the user gets a
> working toolchain by default, but they could still swap in different
> versions of qbe/harec using the QBE/HAREC environment variables.
Yes, that's what I meant. (Sorry for the late reply :))

    -- (