easy_suckless.sh : pour compiler facilement de bons prog

Trucs et Astuces
#1

Bonjour!
Pour tous les fans des logiciels proposés par suckless.org, ou pour ceux qui ont du mal à se lancer dans la compilation de leur logiciels, voici un petit script pouvant les aider.
Il permet à l’heure actuelle, pour dwm, dmenu, surf, st et tabbed :
-compiler à partir d’une archive, ou du dépot hg
-Appliquer un des patchs proposés sur le site officiel
-Éditer facilement le config.h avant la compilation, pour configurer le programme.

Ce qu’il manque au script :
-Normalement, la fonction _patch_hg et _patch_tarball doivent différencier s’il s’agit d’un fichier .diff ou .c . Cependant, il télécharge les 2, et je ne comprend pas pourquoi il refuse de les différencier. Pourtant, ça marche lorsque je fais ces tests en console Je dois fatiguer depuis ce matin sur ce script. :s
-De nouvelles adresses de patch, notamment ceux dénichés par eol pour dmenu.
-D’utiliser autre chose que sudo pour passer en root
-de meilleurs controles d’erreurs
-Changer le répertoire d’installation facilement. Pour l’instant, cela se passe dans /usr/local/bin. Pour y remédier, si vous le souhaiter, vous pouvez taper ceci ensuite :

Le script ressemble à ça :

edit : Maintenant que tabbed est dans les dépots, on peut le configurer à partir des sources debian. cependant, aujourd’hui, les sources semblent mal faites… si quelqu’un en sait plus…

#2

Il a l’air marrant ton script, :slightly_smiling:
si tu veux donner le choix du répertoire d’installation,
tu peux proposer l’édition de la ligne PREFIX dans les config.mk.

#3

Pourquoi ne pas respecter le saint Graal de notre distribution à savoir APT ?
J’ai déjà décris la méthode pour dwm dans la section approprié. Ça permet d’avoir une gestion centralisée, de les désinstaller sans se poser de problème d’avoir une installation parfaitement pérenne, …

Je sais que certains logiciels comme surf ne sont pas dans les dépôt alors pourquoi ne pas créer le paquet ? Ton script pour le construire.

#4

J’aimerais beaucoup Misterfreeze, mais je ne suis pas encore arrivé à quelque chose de concluant avec la méthode que tu proposes. Et ce script n’est que une ébauche pour l’instant, il reste beaucoup à faire (j’en ai rajouté dans le premier post).
De plus, le mieux serait de faire des paquets vraiment à jour, à partir des sources hg par exemple, et là, niveau création de paquets, c’est dur dur :slightly_smiling:

@eol : il n’y aurait pas une autre possiblité, comme avec les autogen par exemple? enfin sinon ce n’est pas bien compliqué à faire :slightly_smiling:
[size=85]
Par ailleurs, je viens de le modifier et d’y ajouter la possibilité d’appliquer des patchs personnalisés.
(je le mets avec ce lien, car je n’arrive pas à modifier les pièces jointes du premier post :slightly_smiling:
thuban.toile-libre.org/easy_suckless.tar.gz[/size]
edit : ah si c’est bon j’ai trouvé :stuck_out_tongue:

Prochaine étape, en faire des paquets :slightly_smiling:

#5

[quote=“MisterFreez”]Pourquoi ne pas respecter le saint Graal de notre distribution à savoir APT ?
J’ai déjà décris la méthode pour dwm dans la section approprié. Ça permet d’avoir une gestion centralisée, de les désinstaller sans se poser de problème d’avoir une installation parfaitement pérenne, …

Je sais que certains logiciels comme surf ne sont pas dans les dépôt alors pourquoi ne pas créer le paquet ? Ton script pour le construire.[/quote]Je comprends le besoin d’une gestion centralisée dans le cas de gros programmes qui t’installes une palanquée de fichiers un peu partout dans le système, mais dans le cas de dwm, dmenu et tabbed par exemple, c’est vraiment sortir un tank pour écraser une mouche, je pense que les utilisateurs de dwm utilisant les binaires des distros sont une infime minorité et ceux utilisant un gestionnaire de connection sont encore moins nombreux et parmi eux ceux qui font des .deb se comptent sur les doigts de la main,
je ne suis pas en train de dire que le nombre de partisans fait l’intérêt d’une méthode, juste que dans le cas présent
la méthode “officielle” Debian ne s’impose pas forcément.

Dans le cas de ces programmes, un make uninstall fait disparaître toute traces de leur existence.
Je vois difficilement un rapport avec la pérennité du système.

Tout pour dire qu’il existe plusieurs usages de dwm et que chacun choisit la méthode de construction
qui convient à son usage.

Sinon pour surf le paquet est déjà en cours de création.

#6

Je pense que je ferais 2 versions du script. Déja, je passe pas mal de temps à modifier le premier, vous pouvez vous en rendre compte, l’archive change tout le temps :slightly_smiling:.
Il manque des tests pour arranger tout ça.
De plus, il faudrait vraiment améliorer le script, au niveau des codes d’erreur, etc etc, pour qu’il ne fasse pas n’importe quoi si une étape rate.

Pour créer les deb, j’y suis finalement arrivé avec ta méthode Misterfreeze (je devais être sur une autre planête pour ne pas y arriver la première fois…).
Je vais essayer de voir comment créer un paquet à partir des sources non-debian avec la méthode de fran.b…

#7

[quote=“thuban”]De plus, le mieux serait de faire des paquets vraiment à jour, à partir des sources hg par exemple, et là, niveau création de paquets, c’est dur dur :slightly_smiling:[/quote]As tu essayé le paquet mercurial-buildpackage?

#8

non, mais là je travaille avec checkinstall, et avec les sources venant de suckless, c’est plutot super (pour l’instant :slightly_smiling: )

#9

Voila, c’est fait pour la génération de paquets debian. Cela demande sans doute des corrections, donc n’hésitez pas à tester pour rapporter les problèmes!
N’hésitez pas non plus à modifier ces scripts!

#10

[quote=“eol”]Je comprends le besoin d’une gestion centralisée dans le cas de gros programmes qui t’installes une palanquée de fichiers un peu partout dans le système, mais dans le cas de dwm, dmenu et tabbed par exemple, c’est vraiment sortir un tank pour écraser une mouche, je pense que les utilisateurs de dwm utilisant les binaires des distros sont une infime minorité et ceux utilisant un gestionnaire de connection sont encore moins nombreux et parmi eux ceux qui font des .deb se comptent sur les doigts de la main,
je ne suis pas en train de dire que le nombre de partisans fait l’intérêt d’une méthode, juste que dans le cas présent
la méthode “officielle” Debian ne s’impose pas forcément.[/quote]
Non elle ne s’impose pas forcément je suis d’accord. Mais il faut je pense alors en informer des conséquences (écrasement de fichiers sans contrôle par APT, gestion des dépendances,…).

Surtout que je ne vois pas en quoi la méthode par création de paquet pose problème. Tu dis que c’est « sortir un tank pour écraser une mouche », mais je vois vraiment pas où est le soucis. La complexité de la création d’un paquet ? Pour ceux qui sont déjà dans les dépôts j’ai donné la méthode ça me semble pas si compliqué.

Et il advient quoi des paquets qui s’en servent ?

Du mal à voir le lien entre utiliser un gestionnaire de fenêtre et la création du dit paquet mais tu as raison pour fait de voir midi à sa porte. La seule chose que j’ai fais c’est poser une question. Je me demandais pourquoi ne pas avoir choisi la méthode debian vu qu’elle me semble simple.

#11

[quote=“MisterFreez”]Non elle ne s’impose pas forcément je suis d’accord. Mais il faut je pense alors en informer des conséquences (écrasement de fichiers sans contrôle par APT, gestion des dépendances,…).[/quote]Euh? On parle des logiciels de chez Suckless dans ce topic. Sur mon système, apt ne sait même pas qu’ils existent, il n’en a jamais écrasé aucun et aucun n’a écrasé de fichier du système,
d’ailleurs je vois vraiment pas comment ça pourrait arriver car les programmes maisons vont par défaut dans /usr/local/ ( chez moi dans ~ ) tandis que ceux du gestionnaire de paquet vont dans /usr/

[quote=“MisterFreez”]Surtout que je ne vois pas en quoi la méthode par création de paquet pose problème. Tu dis que c’est « sortir un tank pour écraser une mouche », mais je vois vraiment pas où est le soucis. La complexité de la création d’un paquet ? Pour ceux qui sont déjà dans les dépôts j’ai donné la méthode ça me semble pas si compliqué.[/quote]Sans être en soi très compliqué, ça l’est tout de même plus qu’un simple make clean install. Ça rajoute des dépendances inutiles, par exemple quilt pour faire un paquet de dwm,
on est chez Kafka?

Et il advient quoi des paquets qui s’en servent ?[/quote]
Euh? Lesquels? Tu connais un paquet qui t’as installé dwm en tant que dépendances. Au pire dwm-tools sera installé par wmii
mais même avec wmii purgé, dwm-tools resterait utile.

[quote=“MisterFreez”]Du mal à voir le lien entre utiliser un gestionnaire de fenêtre et la création du dit paquet mais tu as raison pour fait de voir midi à sa porte. La seule chose que j’ai fais c’est poser une question. Je me demandais pourquoi ne pas avoir choisi la méthode debian vu qu’elle me semble simple.[/quote]Je trouve le choix de la méthode de construction intimement liée à l’usage que l’on a du programme,
par exemple si je démarrais dwm par l’intermédiaire d’un gestionnaire de connexion, je prendrais peut-être la peine d’en faire un paquet,
mais dans mon cas c’est totalement inutile. Je ne choisis pas la méthode Debian pour la raison inverse à la tienne,
elle me semble tirée par les cheveux pour l’usage que j’ai de ces programmes.

Tu t’est déjà demandé pourquoi cette communauté s’appelle Suckless ?
Je crois que c’est parce que le but de leur programmes est d’aller au plus simple tout en étant le plus léger possible.
Eux-même disent sur leur site qu’il est totalement inutile de faire des binaires de leur programmes :

Après chacun comme il veut, c’est vrai qu’en faire un paquet peut-être intéressant
pour apprendre à faire des paquets en commençant par des programmes simples.
(Là je ne parle pas de Surf)

#12

[quote=“eol”]Tu t’est déjà demandé pourquoi cette communauté s’appelle Suckless ?
Je crois que c’est parce que le but de leur programmes est d’aller au plus simple tout en étant le plus léger possible.[/quote]
Pourquoi n’utilise tu pas stali plutôt que Debian ? Ou slakware si stali n’est pas suffisamment stable ? Ce sont deux distributions qui ont ces objectifs pour l’ensemble du système. :slightly_smiling:

Personnellement (mais c’est personnel, hein ? à la base j’ai juste posé une question) j’apprécie la rigueur Debian et j’essaie de me rattacher le plus possible aux méthodes Debian parce que je sais que je ne me mordrais jamais les doigts.

Au passage ce n’est pas parce que quelque chose ne sais jamais produit qu’il ne se produiras pas.

C’est qui kafka ?

#13

eh bien dites donc, vous êtes en forme les gars! :unamused:
Je ne sais pas si vous avez pris le temps de regarder ce que j’ai fait pour modifier le fichier config.mk . C’est vraiment pas super et ça ne marche pas comme je voudrais. Alors bien sûr, on pourrait remplacer cette fonction par une simple édition du fichier config.mk par l’utilisateur, mais je trouve ça moins facile à appréhender, surtout si l’on ne sait pas très bien ce que l’on fait.
Comment pourrais-t-on améliorer cette fonction ? :

###Fonction pour changer le répertoire de destination _ch_destdir () { echo "Où voulez vous installer ce programme? (défaut=/usr/local)" read DESTDIR if [ -z "$DESTDIR" ]; then DESTDIR=/usr/local fi if [ -e config.mk ]; then mv config.mk config.mk.old cat config.mk.old |sed 's/PREFIX\ =\ \/usr\/local//g' >> config.mk.mod echo "PREFIX = $DESTDIR" > config.mk cat config.mk.mod >> config.mk else exit 4 fi }

#14

Bonjour,

T’inquiète, il n’y aucune aggressivité dans nos propos, on discute juste de nos points de vue respectifs. :slightly_smiling:

[quote=“thuban”]Je ne sais pas si vous avez pris le temps de regarder ce que j’ai fait pour modifier le fichier config.mk . C’est vraiment pas super et ça ne marche pas comme je voudrais. Alors bien sûr, on pourrait remplacer cette fonction par une simple édition du fichier config.mk par l’utilisateur, mais je trouve ça moins facile à appréhender, surtout si l’on ne sait pas très bien ce que l’on fait.
Comment pourrais-t-on améliorer cette fonction ? :

###Fonction pour changer le répertoire de destination _ch_destdir () { echo "Où voulez vous installer ce programme? (défaut=/usr/local)" read DESTDIR if [ -z "$DESTDIR" ]; then DESTDIR=/usr/local fi if [ -e config.mk ]; then mv config.mk config.mk.old cat config.mk.old |sed 's/PREFIX\ =\ \/usr\/local//g' >> config.mk.mod echo "PREFIX = $DESTDIR" > config.mk cat config.mk.mod >> config.mk else exit 4 fi }[/quote]Pour ma part j’estime que les programmes compilés à la main et leurs fichiers n’ont rien à faire dans /usr/
et ses sous-répertoires exceptés /usr/local/, je pense cela pour les raisons que MisterFreeze a évoqué plus haut,
à savoir une distinction plus facile par le système de ce qu’il peut toucher ou pas.
( au cas où quelqu’un installe deux fois les mêmes choses deux deux manières différentes )

La seule alternative que je considère à /usr/local est ${HOME}, la première chose que je faisais quand je découvrais
un projet de chez suckless est d’éditer la ligne PREFIX de config.mk de cette manière :PREFIX = ${HOME}ce qui me permet de faire mon make clean install en tant que simple utilisateur et de ne pas devoir passer root chaque fois
que j’ai besoin de changer la configuration d’un de ces programmes.

Donc pour en revenir à ta fonction, je ne sais pas si tu veux réellement laisser le choix total du répertoire d’installation ?
Sinon, en limitant les choix à ce qui est plus raisonnable, tu pourrais proposer :

  1. Garder le choix par défaut du système pour les programmes compilés
  2. Utiliser le répertoire utilisateur
    et vraiment à la rigueur si tu y tiens mais je ne trouve pas l’idée très bonne :
  3. Utiliser les même répertoires que le système pour ses paquets binaires

ensuite si l’utilisateur a choisi 1), le script ne fais rien et passe à la suite,
si l’utilisateur a choisi 2) le script fait mv config.mk config.mk.orig cat config.mk.orig |sed 's/\/usr\/local/${HOME}/' > config.mket si l’utilisateur choisit 3),
c’est comme pour deux en remplaçant ${HOME} par ce qu’il faut.

J’espère que ma petite proposition te sera utile

#15

L’option pour installer dans son propre répertoire est util pour ceux qui n’ont pas un accès root à la machine.

Sinon il y a aussi opt.

#16

[quote=“MisterFreez”]Pourquoi n’utilise tu pas stali plutôt que Debian ? Ou slakware si stali n’est pas suffisamment stable ? Ce sont deux distributions qui ont ces objectifs pour l’ensemble du système. :slightly_smiling: [/quote]C’est vrai, mais étant débutant (ça fait à peine plus d’un an que j’utilise Linux ), j’ai aussi apprécié de pouvoir utiliser un système fonctionnel sans avoir eu à le construire moi-même de A à Z et j’apprécie la démarche de Debian de rendre tout accessible au débutant.

En ce qui concerne le système de base, je partage totalement ton opinion, pour tout ce qui est plus personnel et qui d’ailleurs termine dans mon répertoire utilisateur, j’aime bien faire à ma sauce. :smt003

[quote=“MisterFreez”]Au passage ce n’est pas parce que quelque chose ne sais jamais produit qu’il ne se produiras pas.[/quote]C’est sûr, mais dans le cas présent je reste confiant.

#17

[quote=“MisterFreez”]L’option pour installer dans son propre répertoire est util pour ceux qui n’ont pas un accès root à la machine.[/quote]Oui, entre autres.
Et aussi pour tout ceux qui aiment garder leur bidouilles à l’écart du système.

[quote=“MisterFreez”]Sinon il y a aussi opt.[/quote]Connais pas, c’est quoi?

#18

http://www.linux-france.org/article/sys/fhs/fhs-3.8.html

[quote=“eol”][quote=“MisterFreez”]Pourquoi n’utilise tu pas stali plutôt que Debian ? Ou slakware si stali n’est pas suffisamment stable ? Ce sont deux distributions qui ont ces objectifs pour l’ensemble du système. :slightly_smiling: [/quote][/quote]C’est vrai, mais étant débutant (ça fait à peine plus d’un an que j’utilise Linux ), j’ai aussi apprécié de pouvoir utiliser un système fonctionnel sans avoir eu à le construire moi-même de A à Z et j’apprécie la démarche de Debian de rendre tout accessible au débutant.

Un an seulement??? Je trouve que tu as beaucoup d’aisance pour un “débutant”

Tu étais sous quel OS avant?? Windose??

#19

Le script générique vient d’être modifié. Il y avait plusieurs erreurs bêtes suite à de multiples modifications.

#20

[quote=“M3t4linux”]Je trouve que tu as beaucoup d’aisance pour un “débutant”[/quote]Merci, mais je me retrouve quand même toujours face aux limites de mon ignorance,
par exemple je n’ai pas de connaissances en programmation et ça
c’est quand même vachement handicapant quand on a envie de participer
à certains projets ou même tout simplement d’expérimenter.

[quote=“M3t4linux”]Tu étais sous quel OS avant?? Windose??[/quote]Non, OSX, mais je n’avais aucune idée de l’existence de la console ou même de l’émulateur de terminal avant de passer à Debian, j’avais vraiment une utilisation ultrabasique d’un ordinateur (uniquement mulitmédia).