Pour essayer de contraindre Emmanuel Dreyfus au silence, lui qui ne
cesse de glisser des «tu devrais écrire sur tel ou tel sujet»[1], je
n'ai rien trouvé de mieux que de raconter comment je me suis occupé
pendant le mois de juillet dernier.
Vous pouvez donc en admirer le résultat en
http://www.onlamp.com/pub/a/bsd/2003/10/02/openbsd_gcc.html
Bonne lecture.
[1] afin de diminuer, pendant ce temps, ma productivité dans d'autres
domaines, bien entendu.
Il connait pas Raoul ce mec.. au 4 coin de Paris on va le retrouver eparpille... facon puzzle
-- sinese
mips
On Mon, 06 Oct 2003 15:35:34 +0200 "J." wrote:
Pour etre precis je me suis juste preoccupe de remplacer autoconf etant donne que l'utilite des autres me laisse perplexe.
La bonne nouvelle c'est que l'alternative en question est deja "diffusee" et en plus sous licence BSD. Bonjour,
Je suis tout à fait d'accord avec toi sur les auto*. Par contre, pourquoi avoir choisi de démarrer un nouveau soft ? J'avais fait une petite étude et la liste des softs essayant de fournir ce type de fonctionalités est assez impressionante. Pourquoi ne pas avoir pris un projet en cours ? C'est une vrai question, sans arrière pensée. Personnelement, je me suis tourné vers scons qui m'a semblé (pour mon besoin) être la meilleure solution.
C'est simple, on va y aller par elimination :
En premier on vire les auto* de ta liste, paf 7 de moins. On peut aussi virer les outils associes aux autotools (comme par exemple checkinstall).
Apres on peut virer ceux qui ne correspondent pas a ce que fais autoconf ce qui elimine plus de la moitie des elements de la liste (bye bye tous les clones de make, convertisseurs de makefiles et compagnie). D'ailleurs si on s'interesse en detail ce qu'on enleve la on trouve meme un colorisateur de Makefile !! Cette liste est limite serieuse :)
Bon apres tout ce menage il me reste 3 clients sans compter mon propre projet. On peut maintenant venir en detail sur ma vision de la chose : Pour moi un outil qui doit servir a configurer du code source doit avoir le moins de dependances possible. Ce qui fait qu'un outil de ce genre qui utilise un language de script pour fonctionner pose un gros probleme. Qui va configurer le language dont l'outil se sert ? Qui plus est ca oblige a installer ce language qui pour un certain nombre de gens ne sera utile qu'a ca. Solution : utiliser ce que l'on est cense trouver par defaut sur toute les plateformes utilises et dans mon cas c'etait la famille unix.
Ceci dit paf on enleve toutes les cochonneries a base de python, java et compagnie. Que nous reste-t-il ? RIEN !!
Ceci dit j'ai trouve quelques projets assez similaires au mien qui ne font pas partie de cette liste. Je peux citer entre autre buildtool qui me semble-t-il est developpe par quelqu'un de chez NetBSD (peut-on confirmer ?). Mais comme l'un de mes objectifs etait lie au probleme pose par les troyans dans le script configure je preferais eviter les solutions a base de scripts.
Voila j'espere que la reponse te satisfairas, mips
On Mon, 06 Oct 2003 15:35:34 +0200
"J." <j.saturne-list@laposte.net> wrote:
Pour etre precis je me suis juste preoccupe de remplacer autoconf
etant donne que l'utilite des autres me laisse perplexe.
La bonne nouvelle c'est que l'alternative en question est deja
"diffusee" et en plus sous licence BSD.
Bonjour,
Je suis tout à fait d'accord avec toi sur les auto*. Par contre,
pourquoi avoir choisi de démarrer un nouveau soft ?
J'avais fait une petite étude et la liste des softs essayant de
fournir ce type de fonctionalités est assez impressionante. Pourquoi
ne pas avoir pris un projet en cours ?
C'est une vrai question, sans arrière pensée. Personnelement, je me
suis tourné vers scons qui m'a semblé (pour mon besoin) être la
meilleure solution.
C'est simple, on va y aller par elimination :
En premier on vire les auto* de ta liste, paf 7 de moins.
On peut aussi virer les outils associes aux autotools (comme par
exemple checkinstall).
Apres on peut virer ceux qui ne correspondent pas a ce que fais
autoconf ce qui elimine plus de la moitie des elements de la liste
(bye bye tous les clones de make, convertisseurs de makefiles
et compagnie). D'ailleurs si on s'interesse en detail ce qu'on enleve
la on trouve meme un colorisateur de Makefile !! Cette liste est
limite serieuse :)
Bon apres tout ce menage il me reste 3 clients sans compter mon propre
projet. On peut maintenant venir en detail sur ma vision de la chose :
Pour moi un outil qui doit servir a configurer du code source doit
avoir le moins de dependances possible. Ce qui fait qu'un outil de ce
genre qui utilise un language de script pour fonctionner pose un gros
probleme. Qui va configurer le language dont l'outil se sert ? Qui
plus est ca oblige a installer ce language qui pour un certain nombre
de gens ne sera utile qu'a ca. Solution : utiliser ce que l'on est
cense trouver par defaut sur toute les plateformes utilises et dans
mon cas c'etait la famille unix.
Ceci dit paf on enleve toutes les cochonneries a base de python, java
et compagnie.
Que nous reste-t-il ? RIEN !!
Ceci dit j'ai trouve quelques projets assez similaires au mien qui ne
font pas partie de cette liste. Je peux citer entre autre buildtool
qui me semble-t-il est developpe par quelqu'un de chez NetBSD (peut-on
confirmer ?). Mais comme l'un de mes objectifs etait lie au probleme
pose par les troyans dans le script configure je preferais eviter les
solutions a base de scripts.
Voila j'espere que la reponse te satisfairas,
mips
Pour etre precis je me suis juste preoccupe de remplacer autoconf etant donne que l'utilite des autres me laisse perplexe.
La bonne nouvelle c'est que l'alternative en question est deja "diffusee" et en plus sous licence BSD. Bonjour,
Je suis tout à fait d'accord avec toi sur les auto*. Par contre, pourquoi avoir choisi de démarrer un nouveau soft ? J'avais fait une petite étude et la liste des softs essayant de fournir ce type de fonctionalités est assez impressionante. Pourquoi ne pas avoir pris un projet en cours ? C'est une vrai question, sans arrière pensée. Personnelement, je me suis tourné vers scons qui m'a semblé (pour mon besoin) être la meilleure solution.
C'est simple, on va y aller par elimination :
En premier on vire les auto* de ta liste, paf 7 de moins. On peut aussi virer les outils associes aux autotools (comme par exemple checkinstall).
Apres on peut virer ceux qui ne correspondent pas a ce que fais autoconf ce qui elimine plus de la moitie des elements de la liste (bye bye tous les clones de make, convertisseurs de makefiles et compagnie). D'ailleurs si on s'interesse en detail ce qu'on enleve la on trouve meme un colorisateur de Makefile !! Cette liste est limite serieuse :)
Bon apres tout ce menage il me reste 3 clients sans compter mon propre projet. On peut maintenant venir en detail sur ma vision de la chose : Pour moi un outil qui doit servir a configurer du code source doit avoir le moins de dependances possible. Ce qui fait qu'un outil de ce genre qui utilise un language de script pour fonctionner pose un gros probleme. Qui va configurer le language dont l'outil se sert ? Qui plus est ca oblige a installer ce language qui pour un certain nombre de gens ne sera utile qu'a ca. Solution : utiliser ce que l'on est cense trouver par defaut sur toute les plateformes utilises et dans mon cas c'etait la famille unix.
Ceci dit paf on enleve toutes les cochonneries a base de python, java et compagnie. Que nous reste-t-il ? RIEN !!
Ceci dit j'ai trouve quelques projets assez similaires au mien qui ne font pas partie de cette liste. Je peux citer entre autre buildtool qui me semble-t-il est developpe par quelqu'un de chez NetBSD (peut-on confirmer ?). Mais comme l'un de mes objectifs etait lie au probleme pose par les troyans dans le script configure je preferais eviter les solutions a base de scripts.
Voila j'espere que la reponse te satisfairas, mips
Miod Vallat
Que nous reste-t-il ? RIEN !!
Si, metaconfig. Il faudrait juste le ressuciter et le maintenir sérieusement.
Que nous reste-t-il ? RIEN !!
Si, metaconfig. Il faudrait juste le ressuciter et le maintenir
sérieusement.
On Mon, 6 Oct 2003 19:19:08 +0000 (UTC) Miod Vallat wrote:
Que nous reste-t-il ? RIEN !!
Si, metaconfig. Il faudrait juste le ressuciter et le maintenir sérieusement.
J'ai beau chercher je ne le trouve pas dans la liste ...
mips
Marwan Burelle
On Tue, 07 Oct 2003 13:20:13 +0200 "J." wrote:
Je suis d'accord que cela doit être le plus portable possible, mais il me semble que perl & python sont déjà très largement portable.
Il ne s'agit pas d'une portabilité du langage, mais de la disponibilité de celui-ci de manière standard. Si perl se retrouve dans de plus en plus d'install de base (il me semble qu'il est nécessaire d'avoir Perl pour compiler gcc) ce n'est pas le cas, en général python ne vient (chez qui ne s'en servent pas eux même) qu'avec des outils qui l'utilisent pour de la configuration ou du script.
L'idée de Mips est que, lorsque tu fait un soft de configuration de compilation, celui-ci doit etre le plus indépendant d'autres éléments de ton système.
Je reprend la dépendance entre gcc et perl, et bien, aujourd'hui pour construire un système autour de gcc comme compilateur, il te faut nécessairement un binaire de celui-ci (ou de perl, ce qui revient au même) pour amorcer ton bootstrap. Pour le compilo c'est pas dramatique, tu ne le reconstruit pas régulièrement, mais pour un outil de configuration qui va servir à la compilationd de nombreux autres éléments, éviter une boucle oeuf/poules, c'est pas mal...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
On Tue, 07 Oct 2003 13:20:13 +0200
"J." <j.saturne-list@laposte.net> wrote:
Je suis d'accord que cela doit être le
plus portable possible, mais il me semble que perl & python sont déjà
très largement portable.
Il ne s'agit pas d'une portabilité du langage, mais de la disponibilité
de celui-ci de manière standard. Si perl se retrouve dans de plus en
plus d'install de base (il me semble qu'il est nécessaire d'avoir Perl
pour compiler gcc) ce n'est pas le cas, en général python ne vient (chez
qui ne s'en servent pas eux même) qu'avec des outils qui l'utilisent
pour de la configuration ou du script.
L'idée de Mips est que, lorsque tu fait un soft de configuration de
compilation, celui-ci doit etre le plus indépendant d'autres éléments de
ton système.
Je reprend la dépendance entre gcc et perl, et bien, aujourd'hui pour
construire un système autour de gcc comme compilateur, il te faut
nécessairement un binaire de celui-ci (ou de perl, ce qui revient au
même) pour amorcer ton bootstrap. Pour le compilo c'est pas dramatique,
tu ne le reconstruit pas régulièrement, mais pour un outil de
configuration qui va servir à la compilationd de nombreux autres
éléments, éviter une boucle oeuf/poules, c'est pas mal...
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
Je suis d'accord que cela doit être le plus portable possible, mais il me semble que perl & python sont déjà très largement portable.
Il ne s'agit pas d'une portabilité du langage, mais de la disponibilité de celui-ci de manière standard. Si perl se retrouve dans de plus en plus d'install de base (il me semble qu'il est nécessaire d'avoir Perl pour compiler gcc) ce n'est pas le cas, en général python ne vient (chez qui ne s'en servent pas eux même) qu'avec des outils qui l'utilisent pour de la configuration ou du script.
L'idée de Mips est que, lorsque tu fait un soft de configuration de compilation, celui-ci doit etre le plus indépendant d'autres éléments de ton système.
Je reprend la dépendance entre gcc et perl, et bien, aujourd'hui pour construire un système autour de gcc comme compilateur, il te faut nécessairement un binaire de celui-ci (ou de perl, ce qui revient au même) pour amorcer ton bootstrap. Pour le compilo c'est pas dramatique, tu ne le reconstruit pas régulièrement, mais pour un outil de configuration qui va servir à la compilationd de nombreux autres éléments, éviter une boucle oeuf/poules, c'est pas mal...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Stephane Dupille
Ok. Mais si tu enleves python & perl, pourquoi ne pas enlevé C ? Bon j'exagère exprès.
:))
Pas la peine de s'emballer là dessus. Mais ce que je veux dire et il me semble que kk1 l'a déjà dit dans un des msg de ce thread (c'est pas toi d'ailleurs ?) : A quoi bon complexifier un soft de 50% pour 1% des utilisateurs ?
Certes, c'est une affaire de mesure, mais avoir un seul source qui puisse se compiler partout permet justement d'éviter les différentes version des sources, qui sont plus ou moins maintenues.
Si pour faire évoluer le soft, il faut modifier une dizaine de versions différentes, cela ne vaut plus le coup de maintenir le machin.
Je suis d'accord que cela doit être le plus portable possible, mais il me semble que perl & python sont déjà très largement portable. Le fait de les éliminer est plus un choix personnel que tu as fait, non ?
Perl n'est pas vraiment en standard partout. Rien que sur FreeBSD, la version de base est une version antédéluvienne. Les seules choses sur lesquelles on puisse vraiment compter, et qui soient portables, ce sont les shells (et encore), et le compilo C (parce que de toute façon, si le compilo n'est pas là, on ne peut pas compiler le bouzin après la configuration).
-- Que sont ces "comité" et cette "autorité de contrôle" ? On peut voter pour leur élection ? On peut se présenter pour être élu ? -+- V. in <http://www.le-gnu.net> : Neuneu for Kontrol ! -+-
Ok. Mais si tu enleves python & perl, pourquoi ne pas enlevé C ? Bon
j'exagère exprès.
:))
Pas la peine de s'emballer là dessus. Mais ce que je
veux dire et il me semble que kk1 l'a déjà dit dans un des msg de ce
thread (c'est pas toi d'ailleurs ?) : A quoi bon complexifier un soft
de 50% pour 1% des utilisateurs ?
Certes, c'est une affaire de mesure, mais avoir un seul source qui
puisse se compiler partout permet justement d'éviter les différentes
version des sources, qui sont plus ou moins maintenues.
Si pour faire évoluer le soft, il faut modifier une dizaine de
versions différentes, cela ne vaut plus le coup de maintenir le
machin.
Je suis d'accord que cela doit être
le plus portable possible, mais il me semble que perl & python sont
déjà très largement portable. Le fait de les éliminer est plus un
choix personnel que tu as fait, non ?
Perl n'est pas vraiment en standard partout. Rien que sur FreeBSD,
la version de base est une version antédéluvienne. Les seules choses
sur lesquelles on puisse vraiment compter, et qui soient portables, ce
sont les shells (et encore), et le compilo C (parce que de toute
façon, si le compilo n'est pas là, on ne peut pas compiler le bouzin
après la configuration).
--
Que sont ces "comité" et cette "autorité de contrôle" ?
On peut voter pour leur élection ?
On peut se présenter pour être élu ?
-+- V. in <http://www.le-gnu.net> : Neuneu for Kontrol ! -+-
Ok. Mais si tu enleves python & perl, pourquoi ne pas enlevé C ? Bon j'exagère exprès.
:))
Pas la peine de s'emballer là dessus. Mais ce que je veux dire et il me semble que kk1 l'a déjà dit dans un des msg de ce thread (c'est pas toi d'ailleurs ?) : A quoi bon complexifier un soft de 50% pour 1% des utilisateurs ?
Certes, c'est une affaire de mesure, mais avoir un seul source qui puisse se compiler partout permet justement d'éviter les différentes version des sources, qui sont plus ou moins maintenues.
Si pour faire évoluer le soft, il faut modifier une dizaine de versions différentes, cela ne vaut plus le coup de maintenir le machin.
Je suis d'accord que cela doit être le plus portable possible, mais il me semble que perl & python sont déjà très largement portable. Le fait de les éliminer est plus un choix personnel que tu as fait, non ?
Perl n'est pas vraiment en standard partout. Rien que sur FreeBSD, la version de base est une version antédéluvienne. Les seules choses sur lesquelles on puisse vraiment compter, et qui soient portables, ce sont les shells (et encore), et le compilo C (parce que de toute façon, si le compilo n'est pas là, on ne peut pas compiler le bouzin après la configuration).
-- Que sont ces "comité" et cette "autorité de contrôle" ? On peut voter pour leur élection ? On peut se présenter pour être élu ? -+- V. in <http://www.le-gnu.net> : Neuneu for Kontrol ! -+-
mips
On Tue, 07 Oct 2003 13:20:13 +0200 "J." wrote:
Bon apres tout ce menage il me reste 3 clients sans compter mon propre projet. On peut maintenant venir en detail sur ma vision de la chose : Pour moi un outil qui doit servir a configurer du code source doit avoir le moins de dependances possible. Ce qui fait qu'un outil de ce genre qui utilise un language de script pour fonctionner pose un gros probleme. Qui va configurer le language dont l'outil se sert ? Qui plus est ca oblige a installer ce language qui pour un certain nombre de gens ne sera utile qu'a ca. Solution : utiliser ce que l'on est cense trouver par defaut sur toute les plateformes utilises et dans mon cas c'etait la famille unix.
Ceci dit paf on enleve toutes les cochonneries a base de python, java et compagnie. Que nous reste-t-il ? RIEN !!
Ok. Mais si tu enleves python & perl, pourquoi ne pas enlevé C ? Bon
Bon je vais developper un peu plus et confirmer la pensee de Marwan. Que trouve t'on de base sur un systeme unix ? Un compilateur C et un shell compatible avec le bourne. Si je prend le cas de python : c'est un language qui n'est pas par defaut dans la majorite (pour ne pas dire la totalite) des plateformes que je teste. Qui plus est je n'utilise pas du tout python (je suis plutot ruby mais ca c'est une autre histoire :), cela m'obiligerait donc a installer python et toutes ses eventuelles dependances (je pense que par exemple debian doit installer plein de gentilles choses avec python comme par exemple tk et donc tcl). Bref je trouve cela tres peu commode alors que j'ai sous la main un compilateur C. La je vois certains venir avec leur gros sabots pour me dire que maintenant perl se trouve sur pas mal de systemes par defaut. En ce qui me concerne la situation etait claire, je hais le perl, je trouve que c'est l'un des languages les plus immondes qui existent. De plus il est trop facile de mettre du code a l'aspect cryptique et donc de cacher du code malicieux. Ceux qui veulent debattre sur le fait que perl est ou n'est pas une merde infame sont pries de s'adresser directement a /dev/null, merci.
j'exagère exprès. Pas la peine de s'emballer là dessus. Mais ce que je veux dire et il me semble que kk1 l'a déjà dit dans un des msg de ce thread (c'est pas toi d'ailleurs ?) : A quoi bon complexifier un soft de 50% pour 1% des utilisateurs ? Je suis d'accord que cela
Ca le complique pour qui ? Le but d'un outil est quand meme d'etre utilise. Cela doit etre transparent vis a vis de l'utilisateur donc ce dernier n'a pas a se soucier en quel langage est programme son outil. En ce qui me concerne mon projet n'a besoin de rien d'autre que ce que peut proposer un systeme unix de base et c'est tout ce que je lui demande :)
doit être le plus portable possible, mais il me semble que perl & python sont déjà très largement portable. Le fait de les éliminer est plus un choix personnel que tu as fait, non ?
Cf ci-dessus, tu as raison pour perl et j'explique l'exclusion de python ou autre langage de script.
Dans tout les cas, je l'accorde, le choix que j'avais fait, était pour mon utilisation et je conviens tout à fait que cela ne te suffise pas.
Pour etre honnete autconf me cassait les couilles depuis un bon moment et j'attendais qu'une alternative voie le jour. Or comme on est jamais mieux servi que par soit-meme j'ai craque et pmk a vu le jour.
mips
On Tue, 07 Oct 2003 13:20:13 +0200
"J." <j.saturne-list@laposte.net> wrote:
Bon apres tout ce menage il me reste 3 clients sans compter mon
propre projet. On peut maintenant venir en detail sur ma vision de
la chose : Pour moi un outil qui doit servir a configurer du code
source doit avoir le moins de dependances possible. Ce qui fait
qu'un outil de ce genre qui utilise un language de script pour
fonctionner pose un gros probleme. Qui va configurer le language
dont l'outil se sert ? Qui plus est ca oblige a installer ce
language qui pour un certain nombre de gens ne sera utile qu'a ca.
Solution : utiliser ce que l'on est cense trouver par defaut sur
toute les plateformes utilises et dans mon cas c'etait la famille
unix.
Ceci dit paf on enleve toutes les cochonneries a base de python,
java et compagnie.
Que nous reste-t-il ? RIEN !!
Ok. Mais si tu enleves python & perl, pourquoi ne pas enlevé C ? Bon
Bon je vais developper un peu plus et confirmer la pensee de Marwan.
Que trouve t'on de base sur un systeme unix ? Un compilateur C et un
shell compatible avec le bourne.
Si je prend le cas de python : c'est un language qui n'est pas par
defaut dans la majorite (pour ne pas dire la totalite) des plateformes
que je teste. Qui plus est je n'utilise pas du tout python (je suis
plutot ruby mais ca c'est une autre histoire :), cela m'obiligerait
donc a installer python et toutes ses eventuelles dependances (je
pense que par exemple debian doit installer plein de gentilles choses
avec python comme par exemple tk et donc tcl). Bref je trouve cela
tres peu commode alors que j'ai sous la main un compilateur C.
La je vois certains venir avec leur gros sabots pour me dire que
maintenant perl se trouve sur pas mal de systemes par defaut. En ce
qui me concerne la situation etait claire, je hais le perl, je trouve
que c'est l'un des languages les plus immondes qui existent. De plus
il est trop facile de mettre du code a l'aspect cryptique et donc de
cacher du code malicieux. Ceux qui veulent debattre sur le fait que
perl est ou n'est pas une merde infame sont pries de s'adresser
directement a /dev/null, merci.
j'exagère exprès. Pas la peine de s'emballer là dessus. Mais ce que
je veux dire et il me semble que kk1 l'a déjà dit dans un des msg de
ce thread (c'est pas toi d'ailleurs ?) : A quoi bon complexifier un
soft de 50% pour 1% des utilisateurs ? Je suis d'accord que cela
Ca le complique pour qui ? Le but d'un outil est quand meme d'etre
utilise. Cela doit etre transparent vis a vis de l'utilisateur donc ce
dernier n'a pas a se soucier en quel langage est programme son outil.
En ce qui me concerne mon projet n'a besoin de rien d'autre que ce que
peut proposer un systeme unix de base et c'est tout ce que je lui
demande :)
doit être le plus portable possible, mais il me semble que perl &
python sont déjà très largement portable. Le fait de les éliminer
est plus un choix personnel que tu as fait, non ?
Cf ci-dessus, tu as raison pour perl et j'explique l'exclusion de
python ou autre langage de script.
Dans tout les cas, je l'accorde, le choix que j'avais fait, était
pour mon utilisation et je conviens tout à fait que cela ne te
suffise pas.
Pour etre honnete autconf me cassait les couilles depuis un bon moment
et j'attendais qu'une alternative voie le jour. Or comme on est jamais
mieux servi que par soit-meme j'ai craque et pmk a vu le jour.
Bon apres tout ce menage il me reste 3 clients sans compter mon propre projet. On peut maintenant venir en detail sur ma vision de la chose : Pour moi un outil qui doit servir a configurer du code source doit avoir le moins de dependances possible. Ce qui fait qu'un outil de ce genre qui utilise un language de script pour fonctionner pose un gros probleme. Qui va configurer le language dont l'outil se sert ? Qui plus est ca oblige a installer ce language qui pour un certain nombre de gens ne sera utile qu'a ca. Solution : utiliser ce que l'on est cense trouver par defaut sur toute les plateformes utilises et dans mon cas c'etait la famille unix.
Ceci dit paf on enleve toutes les cochonneries a base de python, java et compagnie. Que nous reste-t-il ? RIEN !!
Ok. Mais si tu enleves python & perl, pourquoi ne pas enlevé C ? Bon
Bon je vais developper un peu plus et confirmer la pensee de Marwan. Que trouve t'on de base sur un systeme unix ? Un compilateur C et un shell compatible avec le bourne. Si je prend le cas de python : c'est un language qui n'est pas par defaut dans la majorite (pour ne pas dire la totalite) des plateformes que je teste. Qui plus est je n'utilise pas du tout python (je suis plutot ruby mais ca c'est une autre histoire :), cela m'obiligerait donc a installer python et toutes ses eventuelles dependances (je pense que par exemple debian doit installer plein de gentilles choses avec python comme par exemple tk et donc tcl). Bref je trouve cela tres peu commode alors que j'ai sous la main un compilateur C. La je vois certains venir avec leur gros sabots pour me dire que maintenant perl se trouve sur pas mal de systemes par defaut. En ce qui me concerne la situation etait claire, je hais le perl, je trouve que c'est l'un des languages les plus immondes qui existent. De plus il est trop facile de mettre du code a l'aspect cryptique et donc de cacher du code malicieux. Ceux qui veulent debattre sur le fait que perl est ou n'est pas une merde infame sont pries de s'adresser directement a /dev/null, merci.
j'exagère exprès. Pas la peine de s'emballer là dessus. Mais ce que je veux dire et il me semble que kk1 l'a déjà dit dans un des msg de ce thread (c'est pas toi d'ailleurs ?) : A quoi bon complexifier un soft de 50% pour 1% des utilisateurs ? Je suis d'accord que cela
Ca le complique pour qui ? Le but d'un outil est quand meme d'etre utilise. Cela doit etre transparent vis a vis de l'utilisateur donc ce dernier n'a pas a se soucier en quel langage est programme son outil. En ce qui me concerne mon projet n'a besoin de rien d'autre que ce que peut proposer un systeme unix de base et c'est tout ce que je lui demande :)
doit être le plus portable possible, mais il me semble que perl & python sont déjà très largement portable. Le fait de les éliminer est plus un choix personnel que tu as fait, non ?
Cf ci-dessus, tu as raison pour perl et j'explique l'exclusion de python ou autre langage de script.
Dans tout les cas, je l'accorde, le choix que j'avais fait, était pour mon utilisation et je conviens tout à fait que cela ne te suffise pas.
Pour etre honnete autconf me cassait les couilles depuis un bon moment et j'attendais qu'une alternative voie le jour. Or comme on est jamais mieux servi que par soit-meme j'ai craque et pmk a vu le jour.
mips
mips
On Tue, 7 Oct 2003 13:34:51 +0200 Marwan Burelle wrote:
Il ne s'agit pas d'une portabilité du langage, mais de la disponibilité de celui-ci de manière standard. Si perl se retrouve dans de plus en plus d'install de base (il me semble qu'il est nécessaire d'avoir Perl pour compiler gcc) ce n'est pas le cas, en
Il faut autoconf pour gcc !!!!! VADE RETRO SATANAS !!!!!!
général python ne vient (chez qui ne s'en servent pas eux même) qu'avec des outils qui l'utilisent pour de la configuration ou du script.
L'idée de Mips est que, lorsque tu fait un soft de configuration de compilation, celui-ci doit etre le plus indépendant d'autres éléments de ton système.
Je reprend la dépendance entre gcc et perl, et bien, aujourd'hui pour construire un système autour de gcc comme compilateur, il te faut nécessairement un binaire de celui-ci (ou de perl, ce qui revient au même) pour amorcer ton bootstrap. Pour le compilo c'est pas dramatique, tu ne le reconstruit pas régulièrement, mais pour un outil de configuration qui va servir à la compilationd de nombreux autreséléments, éviter une boucle oeuf/poules, c'est pas mal...
Tout a fait.
mips
On Tue, 7 Oct 2003 13:34:51 +0200
Marwan Burelle <burelle@lri.fr> wrote:
Il ne s'agit pas d'une portabilité du langage, mais de la
disponibilité de celui-ci de manière standard. Si perl se retrouve
dans de plus en plus d'install de base (il me semble qu'il est
nécessaire d'avoir Perl pour compiler gcc) ce n'est pas le cas, en
Il faut autoconf pour gcc !!!!! VADE RETRO SATANAS !!!!!!
général python ne vient (chez qui ne s'en servent pas eux même)
qu'avec des outils qui l'utilisent pour de la configuration ou du
script.
L'idée de Mips est que, lorsque tu fait un soft de configuration de
compilation, celui-ci doit etre le plus indépendant d'autres
éléments de ton système.
Je reprend la dépendance entre gcc et perl, et bien, aujourd'hui
pour construire un système autour de gcc comme compilateur, il te
faut nécessairement un binaire de celui-ci (ou de perl, ce qui
revient au même) pour amorcer ton bootstrap. Pour le compilo c'est
pas dramatique, tu ne le reconstruit pas régulièrement, mais pour un
outil de configuration qui va servir à la compilationd de nombreux
autreséléments, éviter une boucle oeuf/poules, c'est pas mal...
On Tue, 7 Oct 2003 13:34:51 +0200 Marwan Burelle wrote:
Il ne s'agit pas d'une portabilité du langage, mais de la disponibilité de celui-ci de manière standard. Si perl se retrouve dans de plus en plus d'install de base (il me semble qu'il est nécessaire d'avoir Perl pour compiler gcc) ce n'est pas le cas, en
Il faut autoconf pour gcc !!!!! VADE RETRO SATANAS !!!!!!
général python ne vient (chez qui ne s'en servent pas eux même) qu'avec des outils qui l'utilisent pour de la configuration ou du script.
L'idée de Mips est que, lorsque tu fait un soft de configuration de compilation, celui-ci doit etre le plus indépendant d'autres éléments de ton système.
Je reprend la dépendance entre gcc et perl, et bien, aujourd'hui pour construire un système autour de gcc comme compilateur, il te faut nécessairement un binaire de celui-ci (ou de perl, ce qui revient au même) pour amorcer ton bootstrap. Pour le compilo c'est pas dramatique, tu ne le reconstruit pas régulièrement, mais pour un outil de configuration qui va servir à la compilationd de nombreux autreséléments, éviter une boucle oeuf/poules, c'est pas mal...
