1- Pour les dépendances, de toute facon gcc retournera une erreur compréhensible si la bibliothèque n'existe pas donc ...
Ok. Soit l'erreur (réelle) suivante:
postproc/libswscale.a(rgb2rgb.o)(.text+0x62b9): In function `rgb24toyv12':
: undefined reference to `w1111'
Tu me suggères quoi comme librairie à installer?
Bon ok, j'avoue, j'ai triché. Il s'agit en fait d'un programme autotoolifié (MPlayer 0.93 patché de partout pour des besoins divers). N'empêche que l'erreur de gcc est totalement insuffisante pour déterminer le soft à installer. Surtout avec un nom de symbole manquant aussi peu parlant.
Plus facile que le ./configure ou on voit des centaines de lignes défiler avec un yes ou un no. Lorsque ca ne marche pas, on installe ce qui est marqué sur les lignes avec no en espérant que ca marchera ...
Faudrait voir à apprendre à se servir de configure avant de décréter qu'il ne sert à rien. Un configure bien fait (ceux d'autoconf en particulier) s'arrête lorsqu'il tombe sur une dépendance manquante critique, et il te le signale bien violemment. Aller te taper la liste des yes/no pour savoir ce qui a bien pu merder, c'est un petit peu vain: si ta compilation foire malgré un configure qui termine avec succès, c'est que l'auteur du programme a raté quelque-chose, pas qu'il manque un truc à ton système.
2- Tu peux compiler dans un répertoire séparé:
gcc src/source.c -o dist/source
Le but de ce genre de manipulation étant quand même de permettre à l'utilisateur de compiler son source dans le répertoire de son choix (typiquement s'il n'a pas les droits en écriture sur les sources). Par exemple:
cd ~/src/killerprogram/
/mnt/cdrom/src/killerprogram-0.1/configure
make
Au terme de cette configuration/compilation, rien n'aura été écrit dans le répertoires des sources, et le répertoire de compilation est donc autonome. Tes makefiles sont loin de permettre ce genre de choses facilement.
3- La cible install est très facile à faire. Il sagit juste de copier des fichiers
Eventuellement il faut déterminer l'endroit ou les copier, mettre à jour un uninstall.sh, etc...
je ne pense pas que je réécrirais les autotools, trop compliqué a mon goût. Je trouve que gérer un Makefile est plus simple que gérer les autotools.
C'est évident, et personne ne remet ça en cause. Ce qu'on dit, simplement, c'est qu'un Makefile ne peut pas être comparé à un couple configure/makefile comme tu le fais, et qu'autotools est une aide formidable pour gérer le couple configure/makefile.
De plus je ne fais pas bien confiance aux outils pour déterminer tout seul les dépendances de mon code.
Et tu fais confiance au compilateur pour écrire ton binaire? Tu es vraiment pas méfiant ;)
Sarcasme mis à part, si tu ne fais pas confiance aux autotools pour gérer configure/makefile, j'ai du mal à concevoir que tu puisse faire confiance à Anjuta pour gérer ton projet.
M'enfin ce que j'en dis...
D'autant qu'il y a une grande partie du code que je ne maitrise pas.
Raison de plus pour faire confiance aux outils, alors, BdM! :)
[^] # Re: Mouais
Posté par Larry Cow . En réponse au message Utiliser Anjuta sans les autotools. Évalué à 3.
Ok. Soit l'erreur (réelle) suivante:
postproc/libswscale.a(rgb2rgb.o)(.text+0x62b9): In function `rgb24toyv12':
: undefined reference to `w1111'
Tu me suggères quoi comme librairie à installer?
Bon ok, j'avoue, j'ai triché. Il s'agit en fait d'un programme autotoolifié (MPlayer 0.93 patché de partout pour des besoins divers). N'empêche que l'erreur de gcc est totalement insuffisante pour déterminer le soft à installer. Surtout avec un nom de symbole manquant aussi peu parlant.
Plus facile que le ./configure ou on voit des centaines de lignes défiler avec un yes ou un no. Lorsque ca ne marche pas, on installe ce qui est marqué sur les lignes avec no en espérant que ca marchera ...
Faudrait voir à apprendre à se servir de configure avant de décréter qu'il ne sert à rien. Un configure bien fait (ceux d'autoconf en particulier) s'arrête lorsqu'il tombe sur une dépendance manquante critique, et il te le signale bien violemment. Aller te taper la liste des yes/no pour savoir ce qui a bien pu merder, c'est un petit peu vain: si ta compilation foire malgré un configure qui termine avec succès, c'est que l'auteur du programme a raté quelque-chose, pas qu'il manque un truc à ton système.
2- Tu peux compiler dans un répertoire séparé:
gcc src/source.c -o dist/source
Le but de ce genre de manipulation étant quand même de permettre à l'utilisateur de compiler son source dans le répertoire de son choix (typiquement s'il n'a pas les droits en écriture sur les sources). Par exemple:
cd ~/src/killerprogram/
/mnt/cdrom/src/killerprogram-0.1/configure
make
Au terme de cette configuration/compilation, rien n'aura été écrit dans le répertoires des sources, et le répertoire de compilation est donc autonome. Tes makefiles sont loin de permettre ce genre de choses facilement.
3- La cible install est très facile à faire. Il sagit juste de copier des fichiers
Eventuellement il faut déterminer l'endroit ou les copier, mettre à jour un uninstall.sh, etc...
je ne pense pas que je réécrirais les autotools, trop compliqué a mon goût. Je trouve que gérer un Makefile est plus simple que gérer les autotools.
C'est évident, et personne ne remet ça en cause. Ce qu'on dit, simplement, c'est qu'un Makefile ne peut pas être comparé à un couple configure/makefile comme tu le fais, et qu'autotools est une aide formidable pour gérer le couple configure/makefile.
De plus je ne fais pas bien confiance aux outils pour déterminer tout seul les dépendances de mon code.
Et tu fais confiance au compilateur pour écrire ton binaire? Tu es vraiment pas méfiant ;)
Sarcasme mis à part, si tu ne fais pas confiance aux autotools pour gérer configure/makefile, j'ai du mal à concevoir que tu puisse faire confiance à Anjuta pour gérer ton projet.
M'enfin ce que j'en dis...
D'autant qu'il y a une grande partie du code que je ne maitrise pas.
Raison de plus pour faire confiance aux outils, alors, BdM! :)