GNU bug report logs - #55151
[PATCH] gnu: Add qbe.

Previous Next

Full log

Message #13 received at 55151 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: paren <at> disroot.org, Jon Eskin <eskinjp <at> gmail.com>, jgart <at> dismail.de,
 55151 <at> debbugs.gnu.org, 53833 <at> debbugs.gnu.org
Subject: Re: bug#53833: [PATCH] gnu: Add qbe.
Date: Mon, 02 May 2022 08:33:22 +0200

Hi Ludo,

Am Sonntag, dem 01.05.2022 um 15:16 +0200 schrieb Ludovic Courtès:
> Hi,
> 
> Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at> skribis:
> 
> > Am Montag, dem 25.04.2022 um 20:05 +0000 schrieb paren <at> disroot.org:
> > 
> > > QBE is now being used in one reasonably mature project:
> > > 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".
> 
> But that’s fine: having a web page at all, or one that doesn’t read
> “experimental”, has never been a criterion for getting a package in
> Guix.
That's not my criterion either.  My critierion is more or less "Will we
have to revision-bump this package daily/every few days because people
want to play with the latest stuff?"  With upstream having seen no
commit for three weeks at this point, I guess it might be fine.

> There’s now a second patch for qbe:
> 
>   https://issues.guix.gnu.org/55151
> 
> I propose to go ahead and apply it, adding anything missing from
> paren’s initial patch.
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.

cproc too seems to grow at a slower pace now.  Might be worth moving
stuff over from guixrus now.  Note that the cproc package has #:tests
#f without an explanation, though, so it needs some polishing.

Cheers

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.