guix-patches
[Top][All Lists]
Advanced

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

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


From: Liliana Marie Prikler
Subject: [bug#55606] [PATCH 2/2] gnu: Add hare.
Date: Sun, 26 Jun 2022 09:18:45 +0200
User-agent: Evolution 3.42.1

Hi,

Am Sonntag, dem 26.06.2022 um 00:39 -0400 schrieb Antero Mejr:
> * gnu/packages/hare.scm (hare): New variable.
> ---
>  gnu/packages/hare.scm | 73
> +++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 73 insertions(+)
> 
> diff --git a/gnu/packages/hare.scm b/gnu/packages/hare.scm
> index a1149499d5..16c7d8e2dd 100644
> --- a/gnu/packages/hare.scm
> +++ b/gnu/packages/hare.scm
> @@ -64,3 +64,76 @@ (define-public harec
>  bootstrap written in C.  Currently, the self-hosting @code{harec}
> rewrite is
>  incomplete, so this is used as the default compiler in the build
> driver.")
>        (license license:gpl3))))
> +
> +(define-public hare
> +  (let ((commit "19e380ccb7dfe2bcab5f94e6bd03004e3e2c6005")
> (revision "0"))
As with harec.
> +    (package
> +      (name "hare")
> +      (version (git-version "0.0.0" revision commit))
> +      (source (origin
> +                (method git-fetch)
> +                (uri (git-reference
> +                      (url "https://git.sr.ht/~sircmpwn/hare";)
> +                      (commit commit)))
> +                (file-name (git-file-name name version))
> +                (sha256
> +                 (base32
> +                 
> "04fk3akj3410f8fxw2ixp6l6f9x54pnnk00c0hx0297p7hdzzzq4"))))
> +      (build-system gnu-build-system)
> +      (arguments
> +       (list #:make-flags
> +             #~(list (string-append "BINDIR=" #$output "/bin")
> +                     (string-append "MANDIR=" #$output "/share/man")
> +                     (string-append "SRCDIR=" #$output "/src")
> +                     (string-append "LOCALSRCDIR=" #$output
> "/src/hare")
> +                     (string-append "HAREC=" #$harec "/bin/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.
> +                     (string-append "PLATFORM=" "linux")
> +                     (string-append "HAREPATH="
> +                                    #$output "/src/hare/stdlib:"
> +                                    #$output "/src/hare/third-
> party")
> +                     (string-append "ARCH="
> +                                    #$(platform-linux-architecture
> +                                       (lookup-platform-by-target-
> or-system
> +                                        (or (%current-target-system)
> +                                            (%current-system)))))
> +                     (string-append "AR=" #$(ar-for-target))
> +                     (string-append "AS=" #$(as-for-target))
> +                     (string-append "LD=" #$(ld-for-target))
> +                     (string-append "QBE=" #$qbe "/bin/qbe")
As with harec.
> +                     (string-append "SCDOC=" #$scdoc "/bin/scdoc")
As with harec.
> +                     "HARECACHE=.cache"
> +                     "BINOUT=.bin")
I suppose neither of those ought to be installed?
> +             #:phases
> +             #~(modify-phases %standard-phases
> +                 (add-after 'unpack 'patch-failing-tests
> +                   (lambda _
> +                     ;; These tests fail due to a NaN-related bug in
> QBE when
> +                     ;; used on glibc.
> +                     (substitute* "math/complex/+test.ha"
> +                       (("@test (fn (cos|cosh|exp)\\(\\) void =)" _
> func)
> +                        func))))
> +                 (add-after 'unpack 'patch-makefile
> +                   (lambda _
> +                     (substitute* "Makefile"
> +                       (("include config.mk") ""))))
> +                 (delete 'configure))))
Why delete configure here, but not in harec?  I'm pretty sure we can
use the same hack for both packages.

> +      (native-inputs (list scdoc))
> +      (inputs (list tzdata))
> +      (propagated-inputs (list binutils harec qbe))
> +      (supported-systems (list "x86_64-linux" "aarch64-linux"
> "riscv64-linux"))
> +      (native-search-paths
> +       (list (search-path-specification
> +              (variable "HAREPATH")
> +              (files '("src/hare/stdlib" "src/hare/third-party")))))
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.
> +      (home-page "https://harelang.org";)
> +      (synopsis "Systems programming language")
> +      (description "Hare is a systems programming language that aims
> to improve
> +on C while retaining its core philosophy. Its principles are:
> +@itemize
> +@item Trust the programmer.
> +@item Provide tools the programmer may use when they don't trust
> themselves.
> +@item Prefer explicit behavior over implicit behavior.
> +@item A good program must be both correct and simple.
> +@end itemize")
> +      (license (list license:gpl3 ;compiler and build driver
> +                     license:mpl2.0))))) ;standard library

Cheers






reply via email to

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