unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: Guillaume Le Vaillant <glv@posteo.net>
Cc: help-guix@gnu.org
Subject: Re: Problems with McCLIM (Common Lisp)
Date: Fri, 04 Sep 2020 18:37:09 +0200	[thread overview]
Message-ID: <877dt9fqh6.fsf@elephly.net> (raw)
In-Reply-To: <875z9mvrpb.fsf@yamatai>


Hi Guillaume,

thank you for your response!  (And to Pierre, whose comments you
commented on.)

> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> I’d like to play with McCLIM, but I don’t know enough about Common Lisp
>> to understand how to launch the examples.
>
> When I packaged McCLIM, I only made the packages for the main McCLIM
> library. IIRC the examples also use some extra extensions that I have
> not packaged, so they might not work out of the box (even if the error
> with mcclim-layouts/tab had not happened).
>
>> Here’s what I’ve done:
>>
>>     guix install sbcl sbcl-mcclim sbcl-slime-swank
>>
>> This is the first question, actually: if I don’t manually install
>> sbcl-slime-swank I get errors complaining about swank being absent.
>> Should sbcl-mcclim propagate sbcl-slime-swank?
>
> sbcl-slime-swank is actually an alias for cl-slime-swank because,
> according to a comment in lisp-xyz.scm, "SLIME does not have a ASDF
> system definition to build all of Swank". So in fact there is no
> pre-compiled package for Swank, and this is why it needs to be 
> available to packages that depend on it (directly or indirectly) so that
> they can compile it before using it.

But shouldn’t it then be propagated?  I had to guess that I might need
to install it.  I think it should just be installed when installing
McClim.

> The SBCL build system currently doesn't accept pre-compiled sbcl-*
> packages having a slash in their name. Slashes are replaced with
> hyphens, and the ASDF system name for the pre-compiled package for
> "mcclim-layouts/tab" is in fact "mcclim-layouts-tab". Some package
> definitions have a phase changing slashes to hyphens in asd files when
> necessary (see for example the package definition for
> sbcl-mcclim-extensions), however the asd files in
> "share/common-lisp/sbcl-source/mcclim/" still use the system names with
> slashes, this is why when loading the "clim-examples.asd" file by hand
> you get an error saying that "mcclim-layouts/tab" would not be found.

So, is this something we need to patch in all the asd files for McClim?
Or is this something we should change in the build system?

I’d like to play with McClim and all its applications to see if it would
be worth doing something like this for Guile :)

> I agree that the asdf-build-system could need an overhaul.
>
> Currently the sbcl-xxx package is the base definition and the cl-xxx and
> ecl-xxx packages are derived from it, I think it would make more sense
> make cl-xxx the base definition and derive sbcl-xxx and ecl-xxx from it.
>
> The "deliver-asd" operation has been fixed in recent versions of ASDF,
> so maybe it would be possible to use it instead of our home-made
> functions to create asd files for the bundles.
>
> Another approach could be not to use ASDF bundles at all, and just use
> the regular compilation operation of ASDF, except the fasl files would
> be put it "/gnu/store/..." instead of "$HOME/.cache/common-lisp/...",
> and our asdf-build-system would indicate to ASDF where to search for the
> files.

I don’t know enough about Common Lisp to give a valuable comment here,
but I’d very much like to be able to install Common Lisp things without
having to do additional work post installation.  Using more “default”
ways to install ASDF bundles perhaps would get us closer to a default
experience.

-- 
Ricardo


  reply	other threads:[~2020-09-04 16:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-13  2:43 Problems with McCLIM (Common Lisp) Ricardo Wurmus
2020-08-13  7:16 ` Pierre Neidhardt
2020-08-13  9:08   ` Guillaume Le Vaillant
2020-09-04 16:37     ` Ricardo Wurmus [this message]
2020-09-05  6:57       ` Pierre Neidhardt
2020-09-05  7:20         ` Ricardo Wurmus
2020-09-05  9:49           ` Guillaume Le Vaillant
2020-09-05 17:52         ` Konrad Hinsen
2020-09-06  7:07           ` Pierre Neidhardt
2020-09-11 14:19             ` Katherine Cox-Buday
2020-09-11 14:40               ` Pierre Neidhardt

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=877dt9fqh6.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=glv@posteo.net \
    --cc=help-guix@gnu.org \
    /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.
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).