Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage C Conversion des arguments de printf()

Conversion des arguments de printf()

69 réponses
Avatar
candide
Ce post reprend Message-ID: <g5ift4$1ckv$1@biggoron.nerim.net>

Marc Espie a écrit :
> In article <487cb490$0$6783$426a34cc@news.free.fr>,
> candide <candide@free.invalid> wrote:
>> Je ne comprends pas ce que ça ajoute par rapport à
>>
>> printf("%u\n",strlen("toto"));
>>
>> puisque size_t est un type entier non signé.
>
> Et quelle taille ? printf est une fonction a nombre variable d'arguments,
> de prototype
> int printf(const char *, ...);
>
> il n'y a donc pas de verif de type passe le format. Si tu es sur une
plateforme
> ou size_t vaut unsigned long, ton printf ne marchera pas: il
recuperera juste
> un unsigned int comme parametre.

Bon j'ai cherché à me documenter sur la question, hélas rien de très
clair. Si je lis la FAQ de clc, il est effectivement explicitement dit
que je dois caster, je le saurai pour la prochaine fois.

Mais que se passe-t-il, étape par étape, quand l'instruction

printf("%u\n",strlen("toto"));


est exécutée ? La valeur de strlen("toto") est convertie dans le type
int parce que printf est variadique, c'est cela ?



_Ensuite_, cette valeur est convertie en unsigned int à cause du
spécificateur %u, c'est ça ?


Maintenant que se passe-t-il, étape par étape, quand l'instruction

printf("%u\n",(unsigned)strlen("toto"));

est exécutée ?

L'expression strlen("toto") est évaluée puis sa valeur est convertie en
unsigned int. Mais ensuite, pourquoi l'argument (unsigned)strlen("toto")
n'est-il pas converti en int puisque c'est un argument d'une fonction
variadique ?


Et puis, je ne vois pas où il est dit dans la norme que les arguments
entiers sont convertis en int. Si j'ai repéré l'endroit adéquat, la
conversion s'appelle "default argument promotion". Pour moi la
promotion, c'est la promotion :

char, short, champs de bit -> int ou unsigned int.




Mais la conversion

size_t (le type le plus large) -> int

c'est plus de la promotion, c'est une dégradation.
Signaler un problème avec ce contenu

9 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
3 4 5 6 7
Avatar
espie
In article <g628lc$8f6$,
Antoine Leca wrote:
En news:g6274t$mf0$, Marc Espie va escriure:
In article <g623ii$mo4$, Antoine Leca wrote:
Exemple pratique : sur certaines architectures, les adresses sont des
adresses de int/click/cluster/que_sais_je, donc un pointeur vers
char (et donc un void*) est plus « gros », à l'adresse classique se
rajoute une sous-adresse pour savoir de quel char il s'agit à
l'intérieur du machin dont on a l'adresse.

Évidemment, dans ce cas-là, sizeof(char*) > sizeof(T*).
[...] Cependant la cause la plus claire de problème est
le cas indirect : comme le void* est plus gros, cela décale les
paramètres suivants; donc en lisant le T* on va lire l'adresse de
objet et c'est OK, on récupère ce que l'on veut; par contre la
sous-adresse qui suit n'a pas été dépilée, et quand la fonction
variadique va lire l'argument suivant, BOUM.



Il me semble me souvenir que c'est explicitement interdit par la
norme, que les cast d'objets vers void* and back preservent la
valeur...



Certes, mais pas la représentation.
Cast vers void* : on rajoute une sous-adresse à 0, et le pointeur résultant
est plus gros.
Cast depuis void* : on vérifie éventuellement que la sous-adresse est à 0
(en fait si elle ne l'est pas on est en plein comportement indéfini, c'est
tout le propos du morceau de norme auquel tu fais référence), on laisse
tomber la sous-adresse et on revient au pointeur maigre original.



Ah oui, t'es encore en train de parler de representation. On avait conclu,
trois messages plus haut, qu'il y avait un probleme, mais qu'effectivement,
ca ne servait a rien de se mettre expres dans un cas a probleme. ;-)
Avatar
Vincent Lefevre
Dans l'article <g61qf9$lhq$,
Marc Espie écrit:

Les quelques avantages de cmake.
- il genere tout seul des trucs qui passent tres bien a travers un
make parallele.



C'est la moindre des choses. Personnellement je compile systématiquement
avec "make -j2", je ne n'ai jamais vu de problème avec les autotools.

- il remplace autoconf/automake/libtool. Surtout libtool, en fait.
Au moins il sait pondre des bibliotheques sans se planter, et
surtout il ne multiplie pas les temps de compilation par deux grace
a un shell-script fourre au milieu.



C'est une bonne chose. Maintenant est-ce que ça a été utilisé sur
autant de plateformes et avec autant de configurations que libtool?
Je demande à voir...

- le systeme de cache de valeurs fonctionne, et est standardisee.



À ma connaissance, le système de cache de valeurs fonctionne aussi
avec les autotools. Mais je le trouve très lourd et inintuitif à
utiliser, ce qui peut poser des problèmes aux développeurs.

- il n'y a pas l'immense bibliotheque de *.m4 d'autoconf, ce qui est a la
fois un inconvenient et une chance, vu qu'il n'y a pas les bugs qui vont
avec.



Mais d'un autre côté, si les développeurs sont obligés de réimplémenter
ce que fait la bibliothèque des *.m4, ils risquent aussi d'ajouter des
bugs, d'autant plus que leur propre code sera moins testé.

Sur des projets existants, plus le projet est complet, plus son
infrastructure de build est a moitie cassee, plus ca va etre dur de
reverse-engineerer pour nettoyer et passer a cmake
<mauvaise langue>ca doit etre le cas de mpfr, par exemple</mauvaise langue>.



On n'a pas de connaissance de problème avec l'infrastructure de build
de MPFR, excepté trois bugs de libtool et la dépendance à l'utilitaire
"diff" ("diff" n'existe pas en standard sur Maemo). Le premier bug est
la détection automatique des flags nécessaire au ld sur de vieilles
versions de Solaris[*] (mais je ne suis pas sûr que cmake sache faire
cela automatiquement). Le 2e problème est que les dernières versions
d'icc ne reconnaissent plus l'option -KPIC (idem, cmake sait-il faire
la différence entre les différentes versions de icc?). Et le 3e est
que libtool pense que sur une machine Linux/SuSE/PowerPC, le RPATH
est prioritaire sur le LD_LIBRARY_PATH, alors que sur cette machine
particulière, c'est l'inverse.

[*] e.g. Solaris 2.7

A cote de ca, certains tres gros projets ont adopte cmake, kde en tete,
et en sont fort contents... entre autres parce que leur build va
incroyablement plus vite, il n'y a qu'a comparer kde3 avec un autotools
*amenage pour essayer d'aller plus vite* et kde4 avec cmake *qui compile
reellement plus vite*, surtout sur des machines multi-processeurs.
La difference est flagrante.



Mais si tu lis les archives de kde-buildsystem, tu verras qu'il y a
des problèmes avec cmake, e.g.

http://mail.kde.org/pipermail/kde-buildsystem/2007-October/004213.html

cmake fonctionne avec d'autres choses que des outils gnu.



Les autotools aussi.

Il ne necessite pas d'utiliser gnu-make, il ne reclame pas
l'installation de gnu-m4,



Les autotools non plus.

et il sait meme pondre des bibliotheques pour MacOS X.



Les autotools aussi.

Bref, tu risques d'attendre tres longtemps avant de voir du cmake dans
tout projet vaguement affilie a la FSF. La ligne du parti etant que
autoconf/automake/libtool c'est bien, et que leurs defauts sont lies
a la complexite de ce qu'ils doivent gerer (tu parles, leur defaut,
c'est surtout un design foireux qui a passe la date de peremption de
10 ans ou a peu pres. Ecrire du meta-truc en perl*4*, en m4, et en Bourne
Shell, il y a de quoi se flinguer).



Il n'y a aucune dépendance à perl4 (ou autre version). Mais tout à fait
d'accord sur la remarque concernant m4 et le Bourne shell (en fait,
plutôt /bin/sh, qui peut soit être un Bourne shell traditionnel, soit
être un POSIX shell).

cote scons, je connais tres mal.



Scons dépend de Python, donc c'est mal, d'autant plus que les différentes
versions de Python ne sont pas compatibles entre elles.

Le plus gros probleme de scons, c'est sans doute qu'il faut un python
d'installe pour s'en servir, tandis que cmake, une fois compile,
fonctionne avec un systeme de base...



Voilà.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Avatar
Vincent Lefevre
Dans l'article <g628lc$8f6$,
Antoine Leca écrit:

> ce qui veut dire que sur ces archis, tu dois reserver de la
> place en plus pour tes void* pour permettre les cast.



C'est toujours vrai (je crois que l'on peut montrer que sizeof(void*) majore
sizeof() de tous les pointeurs vers objets, en tous cas c'est une propriété
souvent utilisée pour déterminer les « alignements universels »).



Je n'ai pas l'impression que la norme garantisse cela. Et comme tu
l'avais dit:

| Une autre classe sont les architectures de débogage: supposons
| une implémentation qui range le type dans le pointeur (en plus
| de l'adresse de l'objet pointé).

Si une telle architecture ne range rien pour void* (et char*) parce que
c'est le type de pointeur générique, alors il y a de grandes chances
d'avoir sizeof(T*) > sizeof(void*) pour les autres pointeurs.

Mais je n'arrive pas à en déduire que pour les fonctions variadiques
dont nous parlions, on est obligé de passer _tous_ les pointeurs
comme des pointeurs void*.



On n'est pas obligé. Il suffit seulement que le code qui va relire les
arguments connaisse le type des arguments en question, non? D'ailleurs
le meilleur exemple doit être scanf.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Avatar
espie
In article <20080721195615$,
Vincent Lefevre <vincent+ wrote:
Dans l'article <g61qf9$lhq$,
Marc Espie écrit:

Les quelques avantages de cmake.
- il genere tout seul des trucs qui passent tres bien a travers un
make parallele.



C'est la moindre des choses. Personnellement je compile systématiquement
avec "make -j2", je ne n'ai jamais vu de problème avec les autotools.



Il y en a pourtant un enorme, tres visible sur des gros projets genre KDE,
qui utilisent fortement du make recursif...

- il remplace autoconf/automake/libtool. Surtout libtool, en fait.
Au moins il sait pondre des bibliotheques sans se planter, et
surtout il ne multiplie pas les temps de compilation par deux grace
a un shell-script fourre au milieu.





C'est une bonne chose. Maintenant est-ce que ça a été utilisé sur
autant de plateformes et avec autant de configurations que libtool?
Je demande à voir...



Il y a pas mal de choses qui sont cassees dans libtool, dont un grand
nombre par design.

Typiquement, ca marche tres mal pour faire du packaging. Ca fait tres
peu de distinction entre repertoire d'installation `pour faire le package'
et repertoire d'installation final.

Typiquement, ca ne sait pas reordonner convenablement des repertoires
d'edition de liens.

Le seul modele de libtool qui fonctionne reellement, a ma connaissance,
c'est linux. Ca suppose que tes bibliotheques sont des objets elf, et
que tu peux passer un path complet a chaque fois.

Pour un machin qui a la base est cense portable, c'est quand meme un
comble.

Par exemple, sous OpenBSD, qui est essentiellement un systeme qui
a garde les anciennes conventions, presque tous les logiciels a base de
libtool sont problematiques a la mise-a-jour: libtool est infoutu de
reconnaitre ses propres repertoires de build et de les foutre avant
/usr/local. Le resultat: tu fais ton editions de liens avec *l'ancienne*
version de ta bibliotheque. Ca foire regulierement.

Le probleme est connu. Toutes les version (ou presque) les mainteneurs
de libtool changent l'ordre des repertoires.
La technique est pourtant simple: suffit de faire un repertoire temporaire
d'edition de liens et d'y mettre des symlinks vers precisement les
bibliotheques que tu veux.

Mais voila... c'est du sale boulot. et puis c'est pas linux. Donc personne
veut se le taper. Le fait que libtool est un atroce shell script n'aide
pas.

Tu disais `utilise sur autant de plateformes' ?

Moi je m'en fous, ce qui m'interesse, c'est qui *fonctionne* parfaitement
sur pas mal de plateformes, et en particulier autre chose que du linux.



- le systeme de cache de valeurs fonctionne, et est standardisee.





À ma connaissance, le système de cache de valeurs fonctionne aussi
avec les autotools. Mais je le trouve très lourd et inintuitif à
utiliser, ce qui peut poser des problèmes aux développeurs.



Me suis mal exprime, c'est plutot la facon d'activer/desactiver certaines
options qui est merdique. Genre, tu as un logiciel installe sur ta machine,
et tu veux qu'autoconf l'ignore... la plupart du temps, tu es oblige d'aller
voir le script, et une fois sur deux, ca merdoie.


- il n'y a pas l'immense bibliotheque de *.m4 d'autoconf, ce qui est a la
fois un inconvenient et une chance, vu qu'il n'y a pas les bugs qui vont
avec.



Mais d'un autre côté, si les développeurs sont obligés de réimplémenter
ce que fait la bibliothèque des *.m4, ils risquent aussi d'ajouter des
bugs, d'autant plus que leur propre code sera moins testé.



vu les bugs existants dans la bibliotheque existante, je ne sais pas si
c'est important. Encore un exemple du meme tonneau: les test
d'internationalisation sont buggues jusqu'a l'os, ils cherchent un
libintl.so, qui n'existent pas chez nous, et decident de linker ensuite
en ajouter /usr/local/lib/libintl.a, au lieu de betement vers un -lintl.

je ne compte plus les logiciels ou il a fallu changer ca a la main...
sans compter que, meme si tu corriges a la source, ca va prendre quinze
plombes pour se propager a tous les logiciels qui s'en servent...

faut dire que le mecanisme d'aclocal.m4 et consorts est un peu complique.
Allez, de tete, c'est quoi qui depend de quoi et est regenere par quel
outil ?

Sur des projets existants, plus le projet est complet, plus son
infrastructure de build est a moitie cassee, plus ca va etre dur de
reverse-engineerer pour nettoyer et passer a cmake
<mauvaise langue>ca doit etre le cas de mpfr, par exemple</mauvaise langue>.



On n'a pas de connaissance de problème avec l'infrastructure de build
de MPFR, excepté trois bugs de libtool et la dépendance à l'utilitaire
"diff" ("diff" n'existe pas en standard sur Maemo). Le premier bug est
la détection automatique des flags nécessaire au ld sur de vieilles
versions de Solaris[*] (mais je ne suis pas sûr que cmake sache faire
cela automatiquement). Le 2e problème est que les dernières versions
d'icc ne reconnaissent plus l'option -KPIC (idem, cmake sait-il faire
la différence entre les différentes versions de icc?). Et le 3e est
que libtool pense que sur une machine Linux/SuSE/PowerPC, le RPATH
est prioritaire sur le LD_LIBRARY_PATH, alors que sur cette machine
particulière, c'est l'inverse.



Tu as la chance de fabriquer une bibliotheque toute seule, je viens de
verifier dans mes logs, et l'ordre des repertoires de link est buggue chez
moi comme d'habitude avec libtool...

Mais si tu lis les archives de kde-buildsystem, tu verras qu'il y a
des problèmes avec cmake, e.g.

http://mail.kde.org/pipermail/kde-buildsystem/2007-October/004213.html



Compare aux problemes des autotools, qui avaient conduit Michael Matz
a hacker un bout de l'infrastructure, c'est epsilonesque...

Bref, tu risques d'attendre tres longtemps avant de voir du cmake dans
tout projet vaguement affilie a la FSF. La ligne du parti etant que
autoconf/automake/libtool c'est bien, et que leurs defauts sont lies
a la complexite de ce qu'ils doivent gerer (tu parles, leur defaut,
c'est surtout un design foireux qui a passe la date de peremption de
10 ans ou a peu pres. Ecrire du meta-truc en perl*4*, en m4, et en Bourne
Shell, il y a de quoi se flinguer).





Il n'y a aucune dépendance à perl4 (ou autre version). Mais tout à fait
d'accord sur la remarque concernant m4 et le Bourne shell (en fait,
plutôt /bin/sh, qui peut soit être un Bourne shell traditionnel, soit
être un POSIX shell).



Ah oui, tu as raison, automake est finalement passe a perl5, et autoconf
aussi. Bon, c'est du perl tout moche (il y a quelqu'un qui n'a pas compris
que les prototypes ne servent pas a ce qu'il pense), mais c'est mieux que
rien...

Ouf !
Avatar
Vincent Lefevre
Dans l'article <g62vgd$sn7$,
Marc Espie écrit:

In article <20080721195615$,
Vincent Lefevre <vincent+ wrote:
>C'est la moindre des choses. Personnellement je compile systématiquement
>avec "make -j2", je ne n'ai jamais vu de problème avec les autotools.



Il y en a pourtant un enorme, tres visible sur des gros projets genre KDE,
qui utilisent fortement du make recursif...



Tu as des références? Parce que sans rien citer, c'est juste du FUD.
Et ce n'est pas parce que ça foire pour KDE que c'est forcément un
problème des autotools, puisqu'à part un certain nombre de règles de
base générées par les autotools, les règles spécifiques sont écrites
par les développeurs du projet, et c'est là qu'il peut y avoir un
problème (au passage, Mutt avait un bug de ce genre pour la génération
de la documentation[*]).

[*] http://dev.mutt.org/trac/ticket/2538

Tu disais `utilise sur autant de plateformes' ?



En tout cas, avec MPFR, on n'a pas de problème, que ce soit sous Linux
(excepté la machine particulière SuSE), Solaris, Mac OS X, NetBSD,
FreeBSD, IRIX. Tu peux le voir par les plateformes supportées et les
divers paquets:

http://www.mpfr.org/mpfr-2.3.1/

>> - le systeme de cache de valeurs fonctionne, et est standardisee.



>À ma connaissance, le système de cache de valeurs fonctionne aussi
>avec les autotools. Mais je le trouve très lourd et inintuitif à
>utiliser, ce qui peut poser des problèmes aux développeurs.



Me suis mal exprime, c'est plutot la facon d'activer/desactiver certaines
options qui est merdique. Genre, tu as un logiciel installe sur ta machine,
et tu veux qu'autoconf l'ignore... la plupart du temps, tu es oblige d'aller
voir le script, et une fois sur deux, ca merdoie.



Je ne comprends pas.

vu les bugs existants dans la bibliotheque existante, je ne sais pas si
c'est important. Encore un exemple du meme tonneau: les test
d'internationalisation sont buggues jusqu'a l'os, ils cherchent un
libintl.so, qui n'existent pas chez nous, et decident de linker ensuite
en ajouter /usr/local/lib/libintl.a, au lieu de betement vers un -lintl.



Là, MPFR n'est pas concerné.

je ne compte plus les logiciels ou il a fallu changer ca a la main...
sans compter que, meme si tu corriges a la source, ca va prendre quinze
plombes pour se propager a tous les logiciels qui s'en servent...



C'est pareil pour tout système de build.

faut dire que le mecanisme d'aclocal.m4 et consorts est un peu complique.
Allez, de tete, c'est quoi qui depend de quoi et est regenere par quel
outil ?



Oui, c'est un problème, notamment si on a besoin de patcher localement
des fichiers des autotools. D'ailleurs même Ralf ne savait pas ce qui
se passait lors d'un des derniers tests.

>Il n'y a aucune dépendance à perl4 (ou autre version). Mais tout à fait
>d'accord sur la remarque concernant m4 et le Bourne shell (en fait,
>plutôt /bin/sh, qui peut soit être un Bourne shell traditionnel, soit
>être un POSIX shell).



Ah oui, tu as raison, automake est finalement passe a perl5, et autoconf
aussi. Bon, c'est du perl tout moche (il y a quelqu'un qui n'a pas compris
que les prototypes ne servent pas a ce qu'il pense), mais c'est mieux que
rien...



Ah, c'est leur langage de programmation. Mais l'utilisateur des autotools
n'y a pas du tout accès (dommage, d'ailleurs, ce serait bien mieux que
d'écrire du m4!).

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Avatar
espie
In article <20080721235703$,
Vincent Lefevre <vincent+ wrote:
Dans l'article <g62vgd$sn7$,
Marc Espie écrit:

In article <20080721195615$,
Vincent Lefevre <vincent+ wrote:
>C'est la moindre des choses. Personnellement je compile systématiquement
>avec "make -j2", je ne n'ai jamais vu de problème avec les autotools.



Il y en a pourtant un enorme, tres visible sur des gros projets genre KDE,
qui utilisent fortement du make recursif...



Tu as des références? Parce que sans rien citer, c'est juste du FUD.



C'est la vitesse sur les repertoires multiples, puisqu'autoconf/automake/libtool
est sequentiel a ce niveau.

C'est la principale raison du changement pour kde4.

Et ce n'est pas parce que ça foire pour KDE que c'est forcément un
problème des autotools, puisqu'à part un certain nombre de règles de
base générées par les autotools, les règles spécifiques sont écrites
par les développeurs du projet, et c'est là qu'il peut y avoir un
problème (au passage, Mutt avait un bug de ce genre pour la génération
de la documentation[*]).

[*] http://dev.mutt.org/trac/ticket/2538

Tu disais `utilise sur autant de plateformes' ?



En tout cas, avec MPFR, on n'a pas de problème, que ce soit sous Linux
(excepté la machine particulière SuSE), Solaris, Mac OS X, NetBSD,
FreeBSD, IRIX. Tu peux le voir par les plateformes supportées et les
divers paquets:

http://www.mpfr.org/mpfr-2.3.1/



Mais mpfr fait des trucs super-simples avec libtool, c'est pour ca
que ca marche a peu pres. Des que c'est un peu plus complexe ca foire.


>> - le systeme de cache de valeurs fonctionne, et est standardisee.



>À ma connaissance, le système de cache de valeurs fonctionne aussi
>avec les autotools. Mais je le trouve très lourd et inintuitif à
>utiliser, ce qui peut poser des problèmes aux développeurs.



Me suis mal exprime, c'est plutot la facon d'activer/desactiver certaines
options qui est merdique. Genre, tu as un logiciel installe sur ta machine,
et tu veux qu'autoconf l'ignore... la plupart du temps, tu es oblige d'aller
voir le script, et une fois sur deux, ca merdoie.



Je ne comprends pas.



Tu veux faire du packaging reproductible -> il faut pouvoir expliquer
a autoconf `prend-moi ca, ca, et ca comme applications, et ne detecte
surtout pas le reste'. C'est le truc qui merdoie regulierement dans nos
builds de packages. Hop, autoconf detecte un truc installe par la, essaie
de compiler, et se vautre, ou te fabrique un package faux, parce que dependant
de trucs que tu n'auras pas sur la machine a l'arrivee...

C'est lie aussi a l'incapacite de l'ensemble a pouvoir specifier:
- un endroit ou chercher les dependances (machine de build)
- un endroit ou seront installees les dependances in fine (machine de prod)
- un emplacement d'installation intermediaire (ca ca marche a peu pres)
- un emplacement d'installation finale.

J'aurais un debut de systeme de packaging qui prend tout ca en compte...
Les principaux blocages sont au niveau de libtool et pkg-config, qu'il va
falloir serieusement charcuter pour avoir la moindre chance que ca fonctionne.

Le plus drole (enfin, si on veut) etant que ca marche tout seul dans la
plupart des cas qui n'utilisent pas autoconf.

Là, MPFR n'est pas concerné.

je ne compte plus les logiciels ou il a fallu changer ca a la main...
sans compter que, meme si tu corriges a la source, ca va prendre quinze
plombes pour se propager a tous les logiciels qui s'en servent...



C'est pareil pour tout système de build.



Et non, pas pour cmake. Evidemment, tu te paies le cout de la compilation
de cmake une fois, mais ce dernier est suffisamment rapide pour generer
ce dont il a besoin au vol: tu ne distribues aucun fichier genere, tu
comptes sur la personne pour installer cmake... ce qui se fait tres bien
aujourd'hui... ca prend peu de ressources de compiler cmake, et de toutes
facons, sur des machines en prod, tu installes des packages... ou si tu es
assez dingue pour preferer une solution a la gentoo, tu assumes les choix
jusqu'au bout.
Avatar
Vincent Lefevre
Dans l'article <g63co4$tg4$,
Marc Espie écrit:

In article <20080721235703$,
Vincent Lefevre <vincent+ wrote:
>Dans l'article <g62vgd$sn7$,
> Marc Espie écrit:
>
>> In article <20080721195615$,
>> Vincent Lefevre <vincent+ wrote:
>> >C'est la moindre des choses. Personnellement je compile systématiquement
>> >avec "make -j2", je ne n'ai jamais vu de problème avec les autotools.
>
>> Il y en a pourtant un enorme, tres visible sur des gros projets genre KDE,
>> qui utilisent fortement du make recursif...
>
>Tu as des références? Parce que sans rien citer, c'est juste du FUD.



C'est la vitesse sur les repertoires multiples,
puisqu'autoconf/automake/libtool est sequentiel a ce niveau.



Ah, je n'avais pas compris. Je pensais que tu parlais de Makefile générés
avec des race conditions si bien qu'un "make -j" foirait. Si c'est un
problème de vitesse, c'est un peu moins grave. J'ai vu pas mal l'emploi
de boucles "for" dans des règles de Makefile générées par les autotools.
Je pense qu'une des conséquences est qu'on ne peut pas générer la doc
et compiler en même temps. Est-ce que tu parles de cela? Le "configure"
généré par les autotools est aussi complètement séquentiel. Est-ce que
cmake est capable d'avoir de tels scripts parallèles (en faisant toujours
attention aux dépendences et race conditions)?

Tu veux faire du packaging reproductible -> il faut pouvoir expliquer
a autoconf `prend-moi ca, ca, et ca comme applications, et ne detecte
surtout pas le reste'. C'est le truc qui merdoie regulierement dans nos
builds de packages.



Les autotools ne sont peut-être pas conçus à la base pour faire du
packaging. Mais je crois que le développeur peut faire ce qu'il faut
dans le configure.in (bon, oui, c'est une grosse limitation, mais
je suppose aussi que cmake en a aussi par son manque de bibliothèques
style celle *.m4 des autotools).

J'aurais un debut de systeme de packaging qui prend tout ca en
compte... Les principaux blocages sont au niveau de libtool et
pkg-config, qu'il va falloir serieusement charcuter pour avoir la
moindre chance que ca fonctionne.



pkg-config est un truc buggé par design qui ne fonctionne que dans un
environnement à peu près "standard". Il rajoute des flags dans le dos
de l'utilisateur qui peut affecter d'autres bibliothèques.

>> je ne compte plus les logiciels ou il a fallu changer ca a la main...
>> sans compter que, meme si tu corriges a la source, ca va prendre quinze
>> plombes pour se propager a tous les logiciels qui s'en servent...
>
>C'est pareil pour tout système de build.



Et non, pas pour cmake. Evidemment, tu te paies le cout de la compilation
de cmake une fois, mais ce dernier est suffisamment rapide pour generer
ce dont il a besoin au vol: tu ne distribues aucun fichier genere, tu
comptes sur la personne pour installer cmake...



Attends... si tu comptes sur la personne pour installer cmake, alors tu
pourrais tout aussi bien exiger à la personne d'installer les autotools;
et alors un autoreconf va regénérer les fichiers. Dans le passé, il y a
eu des incompatibilités entre les différentes versions, mais il me semble
que ce n'est plus le cas (pas vu de problème sur plusieurs logiciels).

--
Vincent Lefèvre - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Avatar
espie
In article <20080722103249$,
Vincent Lefevre <vincent+ wrote:
Attends... si tu comptes sur la personne pour installer cmake, alors tu
pourrais tout aussi bien exiger à la personne d'installer les autotools;
et alors un autoreconf va regénérer les fichiers. Dans le passé, il y a
eu des incompatibilités entre les différentes versions, mais il me semble
que ce n'est plus le cas (pas vu de problème sur plusieurs logiciels).



Moi j'en vois encore plein, des problemes... pas mal de cas ou c'est
pas clair du tout:
- ce qu'il faut faire tourner;
- d'ou sortent les fichiers m4 qui vont avec.
Avatar
Thierry B.
--{ Vincent Lefevre a plopé ceci: }--

cote scons, je connais tres mal.



Scons dépend de Python, donc c'est mal, d'autant plus que les différentes
versions de Python ne sont pas compatibles entre elles.



Coté scons, dont je suis en train de lire la doc, je ne sais pas
si il dépend de 'features' changeant entre les versions. Mais
l'arrivée prochaine de Python 3 risque de chager la donne :(


--
Euh, juste par pure curiosité technique. Comment est défini le barycentre
sur une variété qui n'est pas globalement difféomorphe à une boule ?


À tes souhaits.


-+- JS in GFA -+- Bien configurer sa curiosite technique.
3 4 5 6 7