Difference between revisions of "Lisp package guidelines (Italiano)"

From ArchWiki
Jump to: navigation, search
(ASDF)
(Things you, the reader, can do)
Line 116: Line 116:
 
maintainers don't want to).
 
maintainers don't want to).
  
== Things you, the reader, can do ==
+
== Cose che l'utente può fare ==
  
* Maintain lisp packages following these guidelines
+
* Mantenere pacchetti lisp seguendo queste linee-guida.
* Update and fix problems with these guidelines
+
* Aggiornare e correggere queste linee-guida
* Keep up with what's changed here
+
* Seguire i cambiamenti di questa pagina
* Provide (polite) thoughts, feedback, and suggestions both on this document and to people's work.
+
* Fornire (educatamente) consigli, pareri e suggerimenti sia su questo documento che sul lavoro delle persone
* Translate this page and future updates to this page.
+
* Tradurre questa pagina e futuri aggiornamenti a questa pagina.

Revision as of 19:09, 2 May 2011


This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.


Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어


External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

Tango-preferences-desktop-locale.pngThis article or section needs to be translated.Tango-preferences-desktop-locale.png

Notes: please use the first argument of the template to provide more detailed indications. (Discuss in Talk:Lisp package guidelines (Italiano)#)
Nota: Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.

Introduzione

Attualmente ci sono relativamente pochi pacchetti lisp disponibili nei repository di Arch. Questo significa che prima o poi, probabilmente, se ne aggiungeranno altri. E' dunque utile pensare, adesso che ce ne sono pochi, a come dovrebbero essere pacchettizzati. Questa pagina vuole essere un punto di riferimento sulle linee guida per i pacchetti lisp. E' bene comunque tenere a mente che questa non è una versione definitiva; se non siete d'accordo con alcune idee suggerite qui, sentitevi liberi di modificare la pagina e proporre qualcosa di migliore.

Struttura delle cartelle e nomi

C'è almeno un pacchetto nel repository base (libgpg-errpor) che include dei file lisp, che sono posizionati in /usr/share/common-lisp/source/gpg-error. Per conformità, gli altri pacchetti lisp dovrebbero installare i propri files in /usr/share/common-lisp/source/. Ogni pacchetto dovrebbe avere la propria cartella, in modo da non creare disordine in questa cartella di base.

La cartella del pacchetto dovrebbe avere lo stesso nome del pacchetto lisp, e non dovrebbe essere nominata come nel repository Arch (o AUR). Questo si applica anche ai pacchetti costituiti soltanto da un file.

Ad esempio, un pacchetto Lisp chiamato cl-ppcre' dovrebbe essere nominato cl-ppcre in AUR e risiedere in /usr/share/common-lisp/source/cl-ppcre. Un pacchetto chiamato alexandria dovrebbe essere nominato cl-alexandria in AUR e risiedere in in /usr/share/common-lisp/source/alexandria.

ASDF

Cercare di evitare l'utilizzo di ASDF-Install per l'installazione di questi pacchetti di sistema.

ASDF può essere necessario o utile per la compilazione e/o il caricamento di pacchetti. In questo caso, è consigliabile che la cartella usata per il registro centrale (la posizione di tutti i link simbolici a *.asd) sia /usr/share/common-lisp/systems/.

Sono stati riscontrati problemi effettuando la compilazione con asdf come parte del processo di compilazione di un pacchetto. Si può risolvere attraverso l'uso di un file package.install di questo tipo:

# cl-ppcre.install
# arg 1:  the new package version
post_install() {
    echo "---> Compiling lisp files <---"

    clisp --silent -norc -x \
        "(load #p\"/usr/share/common-lisp/source/asdf/asdf\") \
        (pushnew #p\"/usr/share/common-lisp/systems/\" asdf:*central-registry* :test #'equal) \
        (asdf:operate 'asdf:compile-op 'cl-ppcre)"

    echo "---> Done compiling lisp files <---"

    cat << EOM

    To load this library, load asdf and then place the following lines
    in your ~/.clisprc.lisp file:

    (push #p"/usr/share/common-lisp/systems/" asdf:*central-registry*)
    (asdf:operate 'asdf:load-op 'cl-ppcre)
EOM
}

post_upgrade() {
    post_install $1
}

pre_remove() {
    rm /usr/share/common-lisp/source/cl-ppcre/{*.fas,*.lib}
}

op=$1
shift

$op $*

Naturalmente, per far funzionare questo esempio, è necessario avere un link simbolico a package.asd nella cartella di sistema di asdf. Durante la compilazione del pacchetto, questo dovrebbe risolvere...

pushd ${_lispdir}/systems
ln -s ../source/cl-ppcre/cl-ppcre.asd .
ln -s ../source/cl-ppcre/cl-ppcre-test.asd .
popd

...dove $_lispdir è ${startdir}/pkg/usr/share/common-lisp. Creando un link con un path relativo piuttosto che assoluto, è possibile garantire che il link rimanga valido anche dopo l'installazione.

Lisp-specific packaging

When possible, do not make packages specific to a single lisp implementation; try to be as cross-platform as the package itself will allow. If, however, the package is specifically designed for a single lisp implementation (i.e., the developers haven't gotten around to adding support for others yet, or the package's purpose is specifically to provide a capability that is built in to another lisp implementation), it is appropriate to make your Arch package lisp-specific.

To avoid making packages implementation-specific, ideally all implementation packages (SBCL, cmucl, clisp) would be built with the PKGBUILD field common-lisp. However, that's not the case (and that would likely cause problems for people who prefer to have multiple lisps at their fingertips). In the meantime, you could (a) not make your package depend on *any* lisp and include a statement in the package.install file telling folks to make sure they have a lisp installed (not ideal), or (b) Take direction from the sbcl PKGBUILD and include a conditional statement to figure out which lisp is needed (which is hackish and, again, far from ideal). Other ideas are welcome.

Also note that if ASDF is needed to install/compile/load the package, things could potentially get awkward as far as dependencies go, since SBCL comes with asdf installed, clisp does not but there is an AUR package, and CMUCL may or may not have it (the author of this doc. knows next to nothing about CMUCL; sorry).

People currently maintaining lisp-specific packages that don't need to be lisp-specific should consider doing at least one of the following:

  • Editing their PKGBUILD(s) to be cross-platform, provided someone else is not already maintaining the same package for a different lisp.
  • Offering to take over maintenance or help with maintenance of the same package for a different lisp, and then combining them into a single package.
  • Offering up their package to the maintainer of a different lisp's version of the same package, so as to allow that person to combine them into a single package.

(Note that joyfulgirl, the author of this doc., currently maintains clisp versions of cl-ppcre and of stumpwm; she is open to either giving up the packages to the maintainers of the SBCL versions or to maintain the new, cross-platform versions herself if the SBCL-version maintainers don't want to).

Cose che l'utente può fare

  • Mantenere pacchetti lisp seguendo queste linee-guida.
  • Aggiornare e correggere queste linee-guida
  • Seguire i cambiamenti di questa pagina
  • Fornire (educatamente) consigli, pareri e suggerimenti sia su questo documento che sul lavoro delle persone
  • Tradurre questa pagina e futuri aggiornamenti a questa pagina.