Gontran a écrit :
>l'ordre dans lequel apparaissent les éléments importe peu dans
>le fichier XML, seule l'imbrication des balises doit être respectée.
Ce n'est pas vrai, tu dois respecter l'ordre que tu as défini dans le DTD
Exemple de fichier XML et DTD qu'utilise les paquets d'Octoz
http://octoz.org/dtd/entry.dtd
http://octoz.org/dtd/examples/infos.xml
Documentation :
http://www.w3schools.com/xml/
http://www.w3schools.com/dtd/
D'ailleurs je rajouterai la balise <license> dans le fichier infos.xml
prochainement.
Le système GAR de LNX-BBC a un système pour copier les licences dans les
paquets d'après la variable LICENSE, je l'implémenterai dans Hedgar.
Merci Gontran pour http://xmlstar.sourceforge.net/ !
Je ne savais pas que l'on pouvez manipuler du XML avec bash.
Je n'ai pas chercher d'ailleurs...
C'est cool ça, parce que là j'utilisai des sed pour récupéré par exemple
la description du fichier XML, c'était pas top top. :)
Pour les fonctions do_make, do_configure par défaut, c'est une très
bonne idée, le nbuild pourra être alors très petit. Mais comme l'a
souligné Leif-, il faut prévoir que certains paquets n'ont pas d'étape
configure (par exemple).
Dans Hedgar, voilà comment ca marche:
En général on a un Makefile standard avec
CONFIGURE_SCRIPTS = $(WORKSRC)/configure
BUILD_SCRIPTS = $(WORKSRC)/Makefile
INSTALL_SCRIPTS = $(WORKSRC)/Makefile
CONFIGURE_ARGS = --prefix=$(prefix) --shared
Ce qui veut dire que ca fait simplement
./configure --prefix=/usr --shared && make && make install
Si un paquet ne possède pas de ./configure, alors on supprime la
variable CONFIGURE_SCRIPTS.
Lorsque les actions génériques ne conviennent plus, un simple custom
fait l'affaire,
on met "INSTALL_SCRIPTS = custom" et on écrit l'action "install-custom".
Exemple avec le Makefile de zlib :
--------------------
GARNAME = zlib
GARVERSION = 1.2.2
CATEGORIES = base
MASTER_SITES = http://www.zlib.net/
DISTFILES = $(GARNAME)-$(GARVERSION).tar.gz
DESCRIPTION = A compression/decompression Library
MAINTAINER = Vincent Fretin <[EMAIL PROTECTED]>
define BLURB
#FIXME: blurb goes here
endef
CONFIGURE_SCRIPTS = $(WORKSRC)/configure
BUILD_SCRIPTS = $(WORKSRC)/Makefile
INSTALL_SCRIPTS = custom
CONFIGURE_ARGS = --prefix=$(prefix) --shared
# --libdir=/lib
include ../category.mk
install-custom:
@cd $(WORKSRC) && \
$(MAKE) prefix=$(DESTDIR)/$(prefix) install && \
cd -
@$(MAKECOOKIE)
post-install:
@mkdir -p $(DESTDIR)/lib
#this line is in LFS 6.0
@mv $(DESTDIR)/usr/lib/libz.so.* $(DESTDIR)/lib
# @rm $(DESTDIR)/lib/libz.so
@ln -sf ../../lib/libz.so.1.2.2 $(DESTDIR)/usr/lib/libz.so
@cd $(WORKSRC) && $(MAKE) clean && \
./configure --prefix=$(prefix) && $(MAKE) && \
make prefix=$(DESTDIR)/$(prefix) install
@chmod 644 $(DESTDIR)/usr/lib/libz.a
@$(MAKECOOKIE)
--------------------
Vous remarquez le post-install qui est exécuter après l'action
install-custom
L'ordre n'a pas d'importance dans le Makefile, post-install aurait bien
pu être avant install-custom, ca aurait été pareil.
On peut écrire n'importe quel action pre- et post-
pre-fetch
post-fetch
pre-patch
post-patch
Les actions seront exécuté au bon moment.
Il y a les actions suivantes
fetch-list fetch checksum makesum extract checkpatch patch
fixup build install reinstall
seulement les actions
fetch extract patch build install
peuvent avoir des pre- et post- actions
Il y a d'autres variables qui peuvent être utilisé
BUILD_ARGS
INSTALL_ARGS
pour les arguments
et CONFIGURE_ENV, BUILD_ENV, INSTALL_ENV pour les mettre des variables
d'environnements
par exemple si on a :
BUILD_ENV = VAR=qqch
BUILD_ARGS = -j1
à l'action build, ca exécutera :
VAR=qqch make -j1
En gros :)
Ncooker devrait avoir cette logique là je pense.
Pour les noms des paquets
Pour Octoz j'ai choisi comme séparateur de champ le underscore _ pour
que ce soit très facile de séparé tous le champs en une commande (@tab =
split("_",$pkgname) en perl)
Les paquet debian utilise aussi le underscore.
L'inconvéniant de mettre un tiret a plusieurs inconvéniant pour le
programmeur
un paquet se nommant
linux-libc-headers-2.6.11.2-2-i686.oz.tgz
est difficile à séparé pour en tirer les infos.
En fait j'ai regardé le script installpkg de slackware et il y a une
bonne méthode pour ce problème. Ca parcourt caratère par caractère le
nom du paquet...
La distribution gobolinux utilise carrémment le doublet tiret -- comme
séparateur.
Moi j'ai adopté le underscore, parce que je trouve ca plus joli, on voit
bien la séparation des champs, et une facilité pour le programmeur.
exemple de nom de paquet pour Octoz :
zlib_1.2.2-2_i686.oz.tgz
Avant les paquets octoz était écrit comme ceci zlib-1.2.2-oz2.tgz
Pareil, j'ai choisi le format 1.2.2-2, pour que l'on est tout de suite
la version du programme et la version du paquet.
J'ai rajouté l'architechture car plus tard Octoz sera peut-être porté
sur ppc, il faut être prévoyant. :)
Après je ne sais pas si vous en aviez déjà discuté ou non...
