[PKGBUILD] un seul source pour plusieurs paquets ?(en cours)

[rafmav]

Quelle meilleure rédaction pour un PKGBUILD à option ?

Je m'explique: un même code source peut donner des versions différentes de binaire en sortie suivant pour quel langage on compile: c, c++; perl, php, tcl...

Le choix dépend des options passées à "./configure", et il est possible de tout configurer ensemble, ou seulement un seul ou quelques uns, avec code de débogage ou non, etc. Les options de make sont différentes.

Et faut-il faire plusieurs packages en sortie ou un seul ?
du genre:
- package-0.0.0.xz si il est seul,
- ou package.c-0.0.0.xz, package.cpp-0.0.0.xz, package.perl-0.0.0.xz, package.php-0.0.0.xz, package.tcl-0.0.0.xz pour plusieurs.


code du build

Code : Tout sélectionner

build() {
...  blablabla...
  #
  # BUILD HERE
  #

  ./autogen.sh
  LDFLAGS="${LDFLAGS/ -Wl,--as-needed/}"
  # c and c++
  ./configure --prefix=/usr || return 1  
  make
  # php
  ./configure --prefix=/usr --enable-php || return 1
  make
  # perl
  ./configure --prefix=/usr --enable-perl --disable-cpp || return 1
  make
  # python
  PYTHON=/usr/bin/python2 ./configure --prefix=/usr --enable-python \
      || return 1
  make static
  cd py_ext
  make mingcmodule.so
  # tcl does not run: fail to find libtcl
  #./configure --prefix=/usr --enable-tcl || return 1
  #make
}

Merci si avis ou suggestions.

[chipster]

Le titre de ton sujet stp

[FoolEcho]

Si on veut se passer de 36000 builds et qu'on ne veut pas éditer un PKGBUILD, je dirais que le plus simple est d'interroger l'utilisateur sur le type de construction désirée (puisqu'à priori, il n'y a pas de restriction sur la syntaxe bash pour un build, on peut faire ce qu'on veut).

Au niveau build(), je décrirais ainsi les choix offerts à l'utilisateur et en récupèrerais la réponse, du genre:

Code : Tout sélectionner

build() {
...
echo "Constructions possibles:"
echo "1- par défaut (aucun support additionnel)"
echo "2- support de php pour faire blahblahblah"
echo "3- support de perl pour faire blahblahblah"
echo "Choix ?"
read choice
case "$choice" in
  1) 
    #compilation / options de compilation
    ;;
  2) 
    #compilation + php / options de compilation
    ;;
  3) 
    #compilation + perl / options de compilation
    ;;
  *)
    #choix incorrect
    ;;
esac
... 
}

L'avantage est un PKGBUILD généraliste. Pas besoin de le décliner.
Le gros inconvénient étant de devoir rapatrier toutes les dépendances pour envisager toutes les compilations possibles la première fois.

Dans cet optique, du coup, pour la fonction package(), je jetterai aussi un oeil sur la capacité de séparer des paquets ( http://wiki.archlinux.fr/PKGBUILD#Paquets_splitt.C3.A9s ) pour deux raisons: faire un joli nom de paquet adéquat (package-c, package-cpp, etc.) mais surtout pour ne garder que les dépendances adéquates selon la compilation retenue.
Attention, je propose comme ça, sans trop savoir si ça pourrait s'utiliser de cette façon, mais disons que le principe du paquet splitté étant de partir des mêmes sources, ça pourrait coller (ça dépend du truc à compiler aussi). En triturant un peu le .install pour finir on devrait pouvoir arriver à construire quelque chose de potable (si quelqu'un a l'habitude de faire ce genre de construction, évidemment ça sera plus simple de confirmer ou d'infirmer mes élucubrations...)
Pour ma part, je n'ai jamais testé, mais je pense qu'un build à options comme tu veux passe par un paquet splitté. Je chercherai de ce côté en tous cas, pour m'appuyer sur des fonctions existantes qui font à peu près ce que tu veux (désolé, culture objet).

[rafmav]

J'ai mis un titre très provisoire, pas d'idées cette fois-ci!