[PATCH 2/2] gnu: Add hare.

---

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

merge 53833 55151 55605

merge 55187 55606

block 55187 by 53833

block 53834 by 53833

thanks

Antero Mejr via Guix-patches via schreef op ma 23-05-2022 om 21:21 [-

0400]:

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]:

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

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]:

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

"LD=TARGET-ld".

Antero Mejr via Guix-patches via ???

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

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

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

---

gnu/packages/hare.scm | 145 ++++++++++++++++++++++++++++++++++++++++++

guix/utils.scm | 6 ++

2 files changed, 151 insertions(+)

create mode 100644 gnu/packages/hare.scm

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:

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:

-- (

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:

I split out as-for-target into a new patch/issue #56224, since it does

not directly involve hare:

---

gnu/packages/hare.scm | 66 +++++++++++++++++++++++++++++++++++++++++++

1 file changed, 66 insertions(+)

create mode 100644 gnu/packages/hare.scm

---

gnu/packages/hare.scm | 73 +++++++++++++++++++++++++++++++++++++++++++

1 file changed, 73 insertions(+)

Hi (,

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

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 kept that part in the new patches.

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?

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:

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.

Hi,

added the others back to CC; don't forget to set those when using guix

send-email.

Am Sonntag, dem 26.06.2022 um 00:39 -0400 schrieb Antero Mejr:

Despite what (guix style) may tell you, revision goes to an extra line.

Should be (which "qbe"), or some elaborate search-input-file. Also qbe

should be a native input.

I do wonder if some of those get embedded into the compiler or how

they're supposed to be used (outside of build time); if you find a

place where harec invokes qbe, you'd need to patch that in the source.

I don't see why it's necessary to state that harec can't self-host yet.

We would need to bootstrap it from C anyways, so having this

architecture in place actually makes things simpler.

Cheers

Hi,

Am Sonntag, dem 26.06.2022 um 00:39 -0400 schrieb Antero Mejr:

As with harec.

Should have a (this-package-input) or (this-package-native-input) for

harec. If it's the latter, (which "harec") might also be acceptable.

As with harec.

As with harec.

I suppose neither of those ought to be installed?

Why delete configure here, but not in harec? I'm pretty sure we can

use the same hack for both packages.

Is there a need to split HAREPATH like that? From a functionality

perspective, a singular "include/hare" or similar ought to be enough.

I'd specifically avoid "src" since it exists "only for reference

purposes" in the FHS. Other distros mandate that the linux kernel

source code be put there.

Cheers

Antero Mejr schreef op zo 26-06-2022 om 00:40 [-0400]:

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]:

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:

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

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.

-- (

On Sun Jun 26, 2022 at 8:18 AM BST, Liliana Marie Prikler wrote:

Yes. The standard library modules and third-party modules are stored in

different directories. (Don't ask... :P)

Well, it contains source code, and Hare makefiles install into /usr/src

by default, so using src makes sense.

-- (

Resolving the issues mentioned above.

---

gnu/packages/hare.scm | 67 +++++++++++++++++++++++++++++++++++++++++++

1 file changed, 67 insertions(+)

create mode 100644 gnu/packages/hare.scm

---

gnu/packages/hare.scm | 74 +++++++++++++++++++++++++++++++++++++++++++

1 file changed, 74 insertions(+)

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

Done.

Done.

Done.

Right, they're temp dirs. I checked the build output and made sure they

are not included.

hare doesn't have a configure, so we have to set the flags for the

build manually. harec does have a configure that correctly sets many

of the build flags, so I used it.

Thanks,

Antero

Antero Mejr schreef op zo 26-06-2022 om 09:59 [-0400]:

What's this input for? Packages shouldn't have tzdata in their inputs,

because it's a bunch of facts about the external world. When doing

this, running hare's equivalent of `date` from an old profile would

give a bogus result because of out-of-date time zone info.

Also, the rebuilding problem, from (gnu packages base):

;;; A "fixed" version of tzdata, which is used in the test suites of glib and R

;;; and a few other places. We can update this whenever we are able to rebuild

;;; thousands of packages (for example, in a core-updates rebuild). This package

;;; will typically be obsolete and should never be referred to by a built

;;; package.

;;;

;;; Please make this a hidden-package if it is different from the primary tzdata

;;; package.

(define-public tzdata-for-tests tzdata)

Greetings,

Maxime.

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

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 09:59 [-0400]:

You can't package the language itself. DYM: ‘The Hare compiler’, or

maybe: ‘The Hare standard library’, or both?

Greetings,

Maxime.

Antero Mejr schreef op zo 26-06-2022 om 10:07 [-0400]:

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:

I forgot to patch the path in leapsec.ha to use for Guix's leapseconds

file. Should I do that, or leave out tzdata?

From the hare mailing list:

"Notably, Hare requires the installation of the leap-seconds.list file in

the tzdata package in order to handle leap seconds properly.

Hare will work in the absence of this file, or of tzdata as a whole, but

users will encounter bugs in timekeeping logic."

Maxime Devos <maximedevos@telenet.be> writes:

I was going to use

"Hare programming language build driver and standard library"

in the next patch.

Antero Mejr schreef op zo 26-06-2022 om 10:30 [-0400]:

Looking at https://harelang.org/distributions/, harec expects it to

be located in /usr/share/zoneinfo/leap-seconds.list by default (not

/gnu/store/.../share/tzdata), so adding tzdata as input doesn't

accomplish anything here.

So to have time zone things working on Guix System, it seems like hare

needs to be patched to support the $TZDIR environment variable (if it

doesn't support that already).

Also, I think there was some mail or message on #guix some time ago

about Guix not installing that particular file yet in the tzdata

package? That would need to be fixed as well ...

Greetings,

Maxime.

Antero Mejr schreef op zo 26-06-2022 om 10:33 [-0400]:

I don't have a clue what a ‘build driver’ is (a kernel-style driver +

something about building -> a compiler inside the (Linux) kernel?

Doesn't seem to apply here). I'd use ‘compiler’ instead, which I

believe to be more widely understood (e.g., it has an entry on

Wikipedia).

Greetings,

Maxime.

Maxime Devos <maximedevos@telenet.be> writes:

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.

Maxime Devos schreef op zo 26-06-2022 om 16:44 [+0200]:

Maybe nevermind. From #guix:

14:47 < nckx> 'The build driver is responsible for collecting input files,

resolving their dependencies, and producing a plan for

compiling your program.' —

https://harelang.org/blog/2021-03-26-high-level-data-structures/

14:48 < nckx> Seemingly not synonymous.

although:

14:51 < maximed> (OTOH, technically 'gcc' isn't the compiler but 'cc1' is ...)

and yet we call 'gcc' a compiler and seems a bit of an implementation detail

to me, so I dunno.

Greetings,

Maxime.

close 55187

thanks

Superseded by #55606.

-- (

On Sun Jun 26, 2022 at 3:07 PM BST, Antero Mejr wrote:

Yes, that's what I meant. (Sorry for the late reply :))

-- (