From: "Ludovic Courtès" <ludo@gnu.org>
To: Philip McGrath <philip@philipmcgrath.com>
Cc: 49280@debbugs.gnu.org
Subject: [bug#49280] [PATCH v2 0/3] gnu: racket: Update to 8.2. Bootstrap from C.
Date: Fri, 30 Jul 2021 23:22:54 +0200 [thread overview]
Message-ID: <87zgu3xzrl.fsf_-_@gnu.org> (raw)
In-Reply-To: <270db91e-24f6-2754-7164-d0406aeebc60@philipmcgrath.com> (Philip McGrath's message of "Sun, 18 Jul 2021 17:35:56 -0400")
Hi Philip,
Sorry for the delay and thanks for the explanations! Comments/answers
follow.
Philip McGrath <philip@philipmcgrath.com> skribis:
> On 7/8/21 5:25 PM, Ludovic Courtès wrote:
>> Philip McGrath <philip@philipmcgrath.com> skribis:
>>
>>> * gnu/packages/racket.scm (racket-next-minimal,racket-next): New variables.
[...]
>> For this there’s already a documented convention (info "(guix)
>> Package
>> Naming"), although part of it is undocumented. The prefix would rather
>> be “racket-” to match what we do with other packages–“ghc-”, “ocaml-”,
>> “guile-”, and so forth.
>
> I wrote these as statements in the hope of eliciting any disagreement :)
>
> The problem I see with using just “racket-” as the prefix is the
> potential for collisions, especially because Racket uses a lot of the
> namespace: for example, "_" is a useful example package for testing
> package issues, and I maintain the "_-exp" package. There don't seem
> to be Racket packages named "minimal" or "next" right now, but they
> seem reasonably likely to be used in the future, and Guix likewise may
> want to add packages that don't correspond directly to a single
> Racket-level package. (In fact, I think this may be necessary to build
> Racket packages with mutually recursive dependencies.) Other Racket
> package names that I think might be less confusing if prefixed with
> “racket-pkg-” include "base", "racket-lib", "unstable", "profile",
> "make", "data", "images", "compiler", "compatibility", "pkg-build",
> and "main-distribution".
I would not worry too much about name collisions. After all, we have
18K packages and a great potential for collisions already. :-)
We can deal with a hypothetical “next” Racket package when it comes into
existence.
> But we don't need to resolve this now, and maybe actually implementing
> that support will clarify what issues really do or don't exist. I will
> just remove this whole comment for now, since I don't need to make a
> choice between "racket-next-minimal" and "racket-minimal-next".
Either way is fine with me. :-)
> In addition to bootstrapping, there are three reasons I know of to
> want Racket BC:
>
> 1. The BC and CS implementations have different C APIs, so some
> low-level code may support BC but not CS. But this isn't usually a
> good reason. Racket packages should support both implementations.
> Embedding applications ideally would also be portable: if it's
> only feasible to support one implementation, it should be CS.
>
> 2. Comparing the BC and CS implementations can be useful for testing
> and debugging, both for packages that use the FFI and when hacking
> on the Racket runtime system itself.
>
> 3. Most importantly, BC supports some architectures that CS does not.
>
> In particular, Racket CS does not (yet) support ppc64le, which Racket
> BC does support. The recommendation to packagers, and what Debian
> does, is
> to explicitly use BC on platforms without CS support:
> https://github.com/racket/racket/issues/3773#issuecomment-832935403
>
> I'm not sure what the most idiomatic way to do this is in Guix.
Once we have a ‘racket-build-system’, it could pick the right Racket as
a function of the target system.
Otherwise we could do a trick of the sort we have for ‘pkg-config’, but
I’d rather avoid that.
Thanks,
Ludo’.
next prev parent reply other threads:[~2021-07-30 21:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-29 21:52 [bug#49280] [PATCH 0/4] gnu: racket: Add racket-next. Bootstrap from C Philip McGrath
2021-06-29 21:57 ` [bug#49280] [PATCH 1/4] gnu: racket: Fix lib-search-dirs configuration Philip McGrath
2021-06-29 21:57 ` [bug#49280] [PATCH 2/4] gnu: racket: Add racket-next and racket-next-minimal Philip McGrath
2021-07-08 21:25 ` [bug#49280] [PATCH 0/4] gnu: racket: Add racket-next. Bootstrap from C Ludovic Courtès
2021-07-18 21:35 ` Philip McGrath
2021-07-19 6:31 ` [bug#49280] [PATCH v2 1/3] gnu: racket: Update to 8.2 Philip McGrath
2021-07-19 6:31 ` [bug#49280] [PATCH v2 2/3] gnu: racket: Unbundle racket-minimal Philip McGrath
2021-07-30 21:33 ` [bug#49280] [PATCH v2 0/3] gnu: racket: Update to 8.2. Bootstrap from C Ludovic Courtès
2021-07-19 6:31 ` [bug#49280] [PATCH v2 3/3] gnu: racket-minimal: " Philip McGrath
2021-07-19 18:48 ` Philip McGrath
2021-07-19 19:46 ` [bug#49280] [PATCH v2 1/3] gnu: racket: Update to 8.2 Leo Prikler
2021-07-19 21:46 ` Philip McGrath
2021-07-20 9:40 ` Leo Prikler
2021-07-25 8:22 ` Philip McGrath
2021-07-25 13:03 ` Leo Prikler
2021-07-25 18:04 ` Philip McGrath
2021-07-30 23:05 ` bug#49280: [PATCH v2 0/3] gnu: racket: Update to 8.2. Bootstrap from C Ludovic Courtès
2021-07-30 21:22 ` Ludovic Courtès [this message]
2021-07-30 21:31 ` [bug#49280] References to unversioned source tarballs Ludovic Courtès
2021-07-30 22:08 ` Philip McGrath
2021-06-29 21:57 ` [bug#49280] [PATCH 3/4] gnu: racket-next: Unbundle racket-next-minimal Philip McGrath
2021-06-29 21:57 ` [bug#49280] [PATCH 4/4] gnu: racket-next-minimal: Bootstrap from C Philip McGrath
2021-07-08 21:43 ` [bug#49280] [PATCH 0/4] gnu: racket: Add racket-next. " Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zgu3xzrl.fsf_-_@gnu.org \
--to=ludo@gnu.org \
--cc=49280@debbugs.gnu.org \
--cc=philip@philipmcgrath.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).