[bug#53833] gnu: Add qbe.

* gnu/packages/c.scm (qbe): New variable.
---
 gnu/packages/c.scm | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)
  

Am Sonntag, dem 06.02.2022 um 20:13 -0500 schrieb jgart:
> * gnu/packages/c.scm (qbe): New variable.
> ---
>  gnu/packages/c.scm | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/gnu/packages/c.scm b/gnu/packages/c.scm
> index 459d996fa2..8966b7b8d0 100644
> --- a/gnu/packages/c.scm
> +++ b/gnu/packages/c.scm
> @@ -142,6 +142,36 @@ (define-public pcc
>      ;; preferred.  See http://pcc.ludd.ltu.se/licenses/ for more
> details.
>      (license (list license:bsd-2 license:bsd-3))))
>  
> +(define-public qbe
> +  (let ((commit "2ca6fb25a238842418019a3f9ee8d1beb1327f7e")
> +        (revision "0"))
> +    (package
> +      (name "qbe")
> +      (version (git-version "0.0" revision commit))
From the homepage: "QBE is in constant change. It is a young project
and I still have many ideas to try."  As always, I don't think it's too
good of an idea to package projects that tell you "this edge will make
you bleed".  Or in the words of the manual

> Occasionally, we package snapshots of upstream’s version control
> system (VCS) instead of formal releases.  This should remain
> exceptional, because it is up to upstream developers to clarify what
> the stable release is.
I think upstream is very clear here that QBE is not yet stable and
therefore not something you'd want in a distro.  Of course, since the
recipe is a rather simple one, you can easily maintain it in your own
channel -- or not package it at all and use it from source with just a
C compiler.

> +      (source
> +        (origin
> +          (method git-fetch)
> +          (uri
> +            (git-reference
> +              (url "git://c9x.me/qbe")
> +              (commit commit)))
> +          (file-name (git-file-name name version))
> +          (sha256
> +           (base32
> +           
> "0qbnsrwk10v0s42vzxy2wvksd8xl8bmxfzqv2a4j4zjaklqgfd6j"))))
> +      (build-system gnu-build-system)
> +      (arguments
> +       `(#:tests? #f ; Tests require a running qemu?
You should be able to add qemu to native-inputs if that's all it takes.
> +         #:make-flags (list (string-append "CC=" ,(cc-for-target))
> +                            (string-append "PREFIX=" %output))
> +         #:phases
> +         (modify-phases %standard-phases
> +           (delete 'configure))))
> +      (synopsis "Backend compiler")
> +      (description "@code{qbe} is a compiler backend.")
It'd be nice if the description was more descriptive :)
Also the synopsis should probably not invert the ordering of "compiler"
and "backend".
> +      (home-page "https://c9x.me/compile/")
> +      (license license:expat))))
> +
>  (define-public libbytesize
>    (package
>      (name "libbytesize")

Cheers
  

On Mon, 07 Feb 2022 10:47:08 +0100 Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> wrote:
> Am Sonntag, dem 06.02.2022 um 20:13 -0500 schrieb jgart:
> > * gnu/packages/c.scm (qbe): New variable.
> > ---
> >  gnu/packages/c.scm | 30 ++++++++++++++++++++++++++++++
> >  1 file changed, 30 insertions(+)
> > 
> > diff --git a/gnu/packages/c.scm b/gnu/packages/c.scm
> > index 459d996fa2..8966b7b8d0 100644
> > --- a/gnu/packages/c.scm
> > +++ b/gnu/packages/c.scm
> > @@ -142,6 +142,36 @@ (define-public pcc
> >      ;; preferred.  See http://pcc.ludd.ltu.se/licenses/ for more
> > details.
> >      (license (list license:bsd-2 license:bsd-3))))
> >  
> > +(define-public qbe
> > +  (let ((commit "2ca6fb25a238842418019a3f9ee8d1beb1327f7e")
> > +        (revision "0"))
> > +    (package
> > +      (name "qbe")
> > +      (version (git-version "0.0" revision commit))
> From the homepage: "QBE is in constant change. It is a young project
> and I still have many ideas to try."  As always, I don't think it's too
> good of an idea to package projects that tell you "this edge will make
> you bleed".  Or in the words of the manual
> 
> > Occasionally, we package snapshots of upstream’s version control
> > system (VCS) instead of formal releases.  This should remain
> > exceptional, because it is up to upstream developers to clarify what
> > the stable release is.
> I think upstream is very clear here that QBE is not yet stable and
> therefore not something you'd want in a distro.  Of course, since the
> recipe is a rather simple one, you can easily maintain it in your own
> channel -- or not package it at all and use it from source with just a
> C compiler.

Hi lilyp,

Thanks for the review. It's much appreciated.

Here's a recent talk from FOSDEM 2022 on qbe by Drew Devault in case
you're interested in finding out more about it:

https://fosdem.org/2022/schedule/event/lg_qbe/

I already have qbe in Guix 'R Us along with cproc:

https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/qbe.scm#L43

If maintainers think it will be ready for Guix in the future ping me or
feel free to send an update as you see fit.

all best,

jgart

https://whereiseveryone.srht.site/
gemini://whereiseveryone.srht.site/

https://sr.ht/~mcf/cproc
  

Hi jgart,

jgart <jgart@dismail.de> skribis:

> I already have qbe in Guix 'R Us along with cproc:
>
> https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/qbe.scm#L43
>
> If maintainers think it will be ready for Guix in the future ping me or
> feel free to send an update as you see fit.

I’m not opposed to including it if it’s useful but like you write, since
you have it in a channel, maybe we can wait until it’s mature enough
before getting it in Guix proper.

I’m closing this issue but feel free to ping us when you think it should
get in.

Thanks,
Ludo’.
  

QBE is now being used in one reasonably mature project: https://harelang.org https://harelang.org/ 

While it's not at 1.0 yet, it's been in development for ~2 (i think) years now.
  

> I'm not asking for a 1.0, I'd be fine with a 0.1 or even a 0.0.1. As
> it stands, every place I look at says "this is experimental" rather
> than "you can use this and it ought to work as intended at least for
> these sample programs".

Ah, I think you misunderstood slightly: I was saying that Hare was not yet at 1.0 yet (although QBE isn't either.) Regardless, I think it is mature enough for Guix, especially as a stable programming language uses it now.

By the way, https://c9x.me/compile is really outdated, so its estimate on QBE's stability is probably inaccurate by now.
  

Hi Liliana,

> IMHO, paren's initial patch is slightly better in quality than 55151,
> but there are two (three) things lacking. First, the synopsis and
> description are subpar. 55151 has a slightly better synopsis, don't
> feel too sure about the description though. Second, the "fix-cc" phase
> from 55151 should be added after unpack ("patch-test-script" sounds
> like a better phase name). It might be better to use (cc-for-target)
> in the substitution rather than gcc, but note that this substitution
> only applies for native compilation anyway.

I have made your suggested improvements, plus substantial changes to the build recipe that allows
you to cross-compile both QBE and cproc. I have confirmed that cross-compilation works for aarch64
and riscv64. Here is the updated code: <https://git.sr.ht/~whereiseveryone/guixrus/tree/master/guixrus/packages/qbe.scm>.

The changes are as follows for qbe:
* Patch the makefile to support cross-building with a TARGET variable. This is done with a standalone
patch.
* Set "TARGET" to the appropriate target system.
* Set the correct supported systems. (It supports x86_64, aarch64, and riscv64 currently.)
* Improve the synopsis and description.
* Update to the latest commit.
Note that tests still aren't provided because they use QEMU.

And cproc:
* Reenable tests. Not sure why they were disabled in the first place...
* Instead of skipping the configuration phase, replace it with an invocation of cproc's hand-written
./configure. Pass the correct arguments to it to allow cross-compilation to aarch64.
* Use gcc:lib as an input to support cross-compilation.
* Set the correct supported systems. (It supports riscv64 only under musl libc right now.)
* Improve the synopsis and description.
* Update to the latest commit.

I think they are ready for upstreaming now. I will send improved patches to the appropriate issue
threads.
  

I just noticed that the QBE makefile patch contains a mistake in the description:

> This patch modifies the QBE makefile to add a TARGET variable that allows us to support
> cross-compiling it. We modify the case...esac in the config.h target to use this variable
> instead of TARGET.

"instead of TARGET" should be "instead of uname". I can't really see much point in submitting a whole v2 patch for that, especially since i've already made further adjustments to the c.scm file for cproc, so could whoever merges this change that please? Thanks!