Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-lisp
Navigation:
Lists: gentoo-lisp: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-lisp@g.o
From: Stelian Ionescu <sionescu@...>
Subject: Re: common-lisp.eclass cleanup
Date: Mon, 15 Oct 2007 15:39:38 +0200
On Mon, Oct 15, 2007 at 12:04:16PM +0200, Marijn Schouten (hkBst) wrote:
>Stelian Ionescu wrote:
>> On Sat, Oct 13, 2007 at 12:05:42PM +0200, Marijn Schouten (hkBst) wrote:
>> [snip]
>>>> I'll try to explain how CL packages work:
>>>>
>>>> 1) a CL package installs exactly one directory under
>>>> /usr/share/common-lisp/source. This is contained in the variable
>>>> $CLPACKAGE and it defaults to $PN. Exception: app-emacs/slime installs a
>>>> package named "swank"
>>> The code shows this is not really true. I couldn't find where a non-default
>>> use was possible. You probably need to set:
>>>
>>> [[ CLPACKAGE == "" ]] && CLPACKAGE=${PN}
>> 
>> there's no need for this construct because setting CLPACKAGE in the
>> ebuild is only meant as an override of the default value
>
>I was thinking of having the variable set before inheriting the eclass, but if
>you inherit first and set later it works as you intended. Please
>comment that.

Setting the variables before inheriting is useful if you want to use
those variables as global parameters to the eclass, and the eclass does
some computations based on those values at the moment of the inheriting;
in this case I merely want to override a default set by the eclass. this
allows me to have clean&little ebuilds with minimal stuff in it,
i.e. which don't set any eclass variable and don't define src_install,
because the defaults work. all for the sake of writing little code

>>> or slime won't be able to install swank.
>>>
>>>> 2) a CL package contains one or more ASDF files(.asd). The variable
>>>> $CLSYSTEMS contains the names of those systems and defaults to $PN
>>>> because in the simplest case there is only one .asd
>>>> The .asd files usually are contained in the toplevel of the source
>>>> directory and get symlinked into /usr/share/common-lisp/systems
>>> The code shows this is not really true. Therefore you cannot set $CLPACKAGE
>>> and expect it to be used by common-lisp_src_install in its call to
>>> common-lisp-system-symlink. Other eclasses use a construct like this:
>>>
>>> [[ CLSYSTEMS == "" ]] && CLSYSTEMS=${PN}
>> 
>> same as before
>
>True. Why does common-lisp-system-symlink check for zero arguments? Is that
>functionality needed by any ebuild?

yes, most ebuilds don't need to specify explicitly the name of the .asd
to install. common-lisp.eclass already has this thing and it worked well
until now

>>>> The eclass has three explicit "public" functions:
>>>>
>>>> 1) common-lisp-install(): must receive at least one argument. It installs
>>>> files or directories(recursively) into /usr/share/common-lisp/source
>>>>
>>>> 2) common-lisp-system-symlink(): when called with no arguments, it
>>>> installs the systems contained in $CLSYSTEMS. The system names must be
>>>> relative paths. Example: CLSYSTEMS="foo1 foo2 src/bar"
>>>> When called with some arguments, it installs those systems, ignoring
>>>> $CLSYSTEMS
>>> If I understand correctly the symlinks make it appear like CLPACKAGE contains
>>> what CLSYSTEMS contains. What is the point of that or why does it need to be
>>> that way?
>> 
>> most CL packages contain precisely one .asd file, named exactly as the
>> package; for example, kmrcl-1.97 contains only the kmrcl.asd system.
>> Having CLPACKAGE=$PN and CLSYSTEMS=$PN is a good default
>
>That is not an answer. Why do we need to have two variables? Why can we not
>collapse them into one?

we always install all code provided by an upstream package in the same
subdirectory of /usr/share/common-lisp/source, even if the tarball
contains multiple ASD systems. for the ease of maintenance(or laziness
if you like) I prefer to install code maintaining the exact tree it had
in the tarball. this can be changed, of course, if we really want it
only exception: cl-sql/clsql(new)

>>>> 3) do-debian-credits(): taken from common-lisp-common.eclass, since I've
>>>> dropped the inheritance on it
>>> Which packages use this 
>> 
>> cl-aima, cl-irc, cl-sql, png, rt and split-sequence
>> 
>>> and what's the point of doing it?
>> 
>> as you know, many CL devs don't do releases(or not even versioning) so
>> mkennedy thought well of using the snapshots made by Debian developers
>> instead of making his own snapshots. It's meant as a way to credit
>> Debian for this
>
>I don't know about many. A few yes. Having Debian oblige them certainly is a
>mixed blessing.

I don't think they're obliged by Debian, rather that Debian devs,
noticing that the devs don't do releases, make snapshots on their own
and use those

> I don't think I like having code in our eclasss merely to give
>credit and not nearly enough ebuilds seem to depend on this. Are any of the
>installed files of practical use?

I don't think so, I left do-debian-credits because mkennedy added
it(probably because he thought it was a good thing) and I have nothing
against it. Being this FOSS, I prefer to add credits rather than remove them

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
Attachment:
pgpuJ7n5nDBib.pgp (PGP signature)
References:
common-lisp.eclass cleanup
-- Stelian Ionescu
Re: common-lisp.eclass cleanup
-- Marijn Schouten (hkBst)
Re: common-lisp.eclass cleanup
-- Stelian Ionescu
Re: common-lisp.eclass cleanup
-- Marijn Schouten (hkBst)
Navigation:
Lists: gentoo-lisp: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: common-lisp.eclass cleanup
Next by thread:
Re: common-lisp.eclass cleanup
Previous by date:
Re: common-lisp.eclass cleanup
Next by date:
Re: common-lisp.eclass cleanup


Updated Jun 17, 2009

Summary: Archive of the gentoo-lisp mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.