Sam Hocevar , dans le message <slrncohud0.5e6.sam+, a écrit :
Pourtant les deux sont très liées et je trouve normal d'avoir un outil qui puisse faire les deux. Par exemple si l'on n'a pas <pthread.h> on ne va pas compiler avec -pthread.
Je ne suis pas d'accord du tout. Il faut faire ça en deux phases :
- d'abord les préférences de compilation, « je veux telle option, je ne veux pas telle autre, et pour cette troisième je m'en fiche » ;
- ensuite une phase de détection de l'installation logicielle disponible.
Si des bibliothèques ne sont pas disponibles pour telle option, la moitié des ./configure en circulation vont simplement afficher deux lignes perdues dans plusieurs centaines d'autres et désactiver l'option. Le seul comportement raisonnable à mon sens serait l'affichage d'un message disant en substance :
Vous avez réclamé l'option foobar, mais elle n'est possible que si la libbazqux est installée. Installez cette bibliothèque ou changez vos options.
Accessoirement, en pratique, les autotools, et surtout libtool, sont souvent extrêmement pénibles quand on souhaite contrôler précisément la compilation. En particulier je compile régulièrement des trucs qui s'installent ainsi :
Régulièrement, libtool parvient à mettre $UTIL/packages/foobar-12.1729 dans RPATH des binaires produits, alors que justement, je n'en veux surtout pas.
Premièrement, l'entête est plus simple dans sa description, mais est nettement plus difficile à lire parce qu'elle n'est pas binaire (il faut prendre en compte les espaces et les tabulations, sauter les commentaires jusqu'à la fin de la ligne, etc.). À l'inverse, tout dans BMP est défini par offsets binaires, ce qui en fait un format trivial à lire.
Franchement, parser l'entête PNM, ce n'est pas la mer à boire du tout. Et il y a plein de champs pénibles à gérer dans l'entête du BMP.
Deuxièmement, un *énorme* défaut de PNM, qui le rend absolument inutilisable comme format standard dans le contexte d'un jeu, c'est qu'il ne sait pas gérer de palette. Une image en 256 couleurs est donc 2 à 4 fois plus grosse que l'équivalent en BMP.
Ah, tu as raison, j'avais oublié cet aspect.
Sam Hocevar , dans le message <slrncohud0.5e6.sam+news@poulet.zoy.org>,
a écrit :
Pourtant les deux sont très liées et je trouve normal d'avoir un
outil qui puisse faire les deux. Par exemple si l'on n'a pas <pthread.h>
on ne va pas compiler avec -pthread.
Je ne suis pas d'accord du tout. Il faut faire ça en deux phases :
- d'abord les préférences de compilation, « je veux telle option, je ne veux
pas telle autre, et pour cette troisième je m'en fiche » ;
- ensuite une phase de détection de l'installation logicielle disponible.
Si des bibliothèques ne sont pas disponibles pour telle option, la moitié
des ./configure en circulation vont simplement afficher deux lignes perdues
dans plusieurs centaines d'autres et désactiver l'option. Le seul
comportement raisonnable à mon sens serait l'affichage d'un message disant
en substance :
Vous avez réclamé l'option foobar, mais elle n'est possible que si
la libbazqux est installée. Installez cette bibliothèque ou changez
vos options.
Accessoirement, en pratique, les autotools, et surtout libtool, sont souvent
extrêmement pénibles quand on souhaite contrôler précisément la compilation.
En particulier je compile régulièrement des trucs qui s'installent ainsi :
Régulièrement, libtool parvient à mettre $UTIL/packages/foobar-12.1729 dans
RPATH des binaires produits, alors que justement, je n'en veux surtout pas.
Premièrement, l'entête est plus simple dans sa description, mais
est nettement plus difficile à lire parce qu'elle n'est pas binaire
(il faut prendre en compte les espaces et les tabulations, sauter les
commentaires jusqu'à la fin de la ligne, etc.). À l'inverse, tout dans
BMP est défini par offsets binaires, ce qui en fait un format trivial à
lire.
Franchement, parser l'entête PNM, ce n'est pas la mer à boire du tout. Et il
y a plein de champs pénibles à gérer dans l'entête du BMP.
Deuxièmement, un *énorme* défaut de PNM, qui le rend absolument
inutilisable comme format standard dans le contexte d'un jeu, c'est
qu'il ne sait pas gérer de palette. Une image en 256 couleurs est donc 2
à 4 fois plus grosse que l'équivalent en BMP.
Sam Hocevar , dans le message <slrncohud0.5e6.sam+, a écrit :
Pourtant les deux sont très liées et je trouve normal d'avoir un outil qui puisse faire les deux. Par exemple si l'on n'a pas <pthread.h> on ne va pas compiler avec -pthread.
Je ne suis pas d'accord du tout. Il faut faire ça en deux phases :
- d'abord les préférences de compilation, « je veux telle option, je ne veux pas telle autre, et pour cette troisième je m'en fiche » ;
- ensuite une phase de détection de l'installation logicielle disponible.
Si des bibliothèques ne sont pas disponibles pour telle option, la moitié des ./configure en circulation vont simplement afficher deux lignes perdues dans plusieurs centaines d'autres et désactiver l'option. Le seul comportement raisonnable à mon sens serait l'affichage d'un message disant en substance :
Vous avez réclamé l'option foobar, mais elle n'est possible que si la libbazqux est installée. Installez cette bibliothèque ou changez vos options.
Accessoirement, en pratique, les autotools, et surtout libtool, sont souvent extrêmement pénibles quand on souhaite contrôler précisément la compilation. En particulier je compile régulièrement des trucs qui s'installent ainsi :
Régulièrement, libtool parvient à mettre $UTIL/packages/foobar-12.1729 dans RPATH des binaires produits, alors que justement, je n'en veux surtout pas.
Premièrement, l'entête est plus simple dans sa description, mais est nettement plus difficile à lire parce qu'elle n'est pas binaire (il faut prendre en compte les espaces et les tabulations, sauter les commentaires jusqu'à la fin de la ligne, etc.). À l'inverse, tout dans BMP est défini par offsets binaires, ce qui en fait un format trivial à lire.
Franchement, parser l'entête PNM, ce n'est pas la mer à boire du tout. Et il y a plein de champs pénibles à gérer dans l'entête du BMP.
Deuxièmement, un *énorme* défaut de PNM, qui le rend absolument inutilisable comme format standard dans le contexte d'un jeu, c'est qu'il ne sait pas gérer de palette. Une image en 256 couleurs est donc 2 à 4 fois plus grosse que l'équivalent en BMP.
