Outil Make simple
TSalm
Je cherche un outil qui me permette de lancer des compilations de faï¿œon
simple sur un projet de plusieurs executables.
Quand je dis simple, je veux dire qui sache trouver automatiquement les
dￜpendances, qui gￜnￜre les fichiers .o seulement s'ils ne sont pas ￜ jour
avec leurs sources, et qui m'oblige ￜ une certaine organisation de mes
sources ï¿œvidemment.
Qui fait que je n'ai plus qu'ￜ lancer une compilation de mon executable,
plein d'autres dï¿œpendances, de cette faï¿œon :
$MON_OUTIL chemin/vers/mon/exe.cpp
Ca existe ?
Merci d'avance pour vos conseils.
-TSalm
Fabien LE LEZ
>Quand je dis simple, je veux dire qui sache trouver automatiquement les
>d�pendances
Un article assez vieux, mais qui te donnera tout de m�me des pistes :
http://freshmeat.net/articles/make-alternatives
James Kanze
> Je cherche un outil qui me permette de lancer des compilations de
> façon simple sur un projet de plusieurs executables.
> Quand je dis simple, je veux dire qui sache trouver automatiquement
> les dépendances, qui génére les fichiers .o seulement s'ils ne sont
> pas à jour avec leurs sources, et qui m'oblige à une certaine
> organisation de mes sources évidemment.
>
> Qui fait que je n'ai plus qu'à lancer une compilation de mon
> executable, plein d'autres dépendances, de cette façon :
> $MON_OUTIL chemin/vers/mon/exe.cpp
> Ca existe ?
Combien d'effort est-ce que tu prêt à investir pour le configurer ?
C'est tout à fait possible de faire quelque chose du genre avec GNU
make, mais il faut un certain effort dans l'écriture des fichiers de
make initiaux. Ensuite, tu crées un alias qui invoque « gmake -f
mon_makefile_de_base.mk », et tu invoques l'alias ; gmake saura faire
la
reste. (C'est plus dans la philosophie des make que tu précises
l'exécutable que tu veux construire, plutôt que la source, mais j'ai
bien réussi à faire marcher la forme avec la source à l'aide d'un tout
petit peu de shell.)
--
James Kanze
Fabien LE LEZ
<james...@gmail.com>:
>C'est tout � fait possible de faire quelque chose du genre avec GNU
>make,
Comment fait-on, avec make, pour g�n�rer automatiquement les
d�pendances ? Si je ne m'abuse, make tout seul ne sait pas de quels .h
un .cpp d�pend.
Jean-Marc Bourguet
Tous les compilateurs que j'utilise ont des flags du genre -M? de GCC, qui
permettent de recuperer l'info. Il suffit d'inclure le resultat dans le
Makefile (ce qui suppose un make qui permet l'inclusion sans erreur si le
fichier n'existe pas, comme GNU make).
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Richard Delorme
Non, en effet. Il faut utiliser l'option -MM du pr�processeur de gcc.
Mais c'est facile d'inclure la commande dans le Makefile :
Par exemple :
#-----8<-----------------------------
depend:
gcc -MM *.cpp > dependencies.mk
# DEPENDANCES
-include dependencies.mk
#-----8<-----------------------------
et un "make depend" g�n�re les d�pendances.
--
Richard
Jean-Marc Bourguet
Je refais automatiquement la dependance avec l'objet. Ca evite de devoir
se poser des questions quand a la necessite de faire un make depend. Donc
pour gcc
CXXFLAGS=-MMD
-include $(OBJECTS:.o=.d)
pour les compilateurs sans equivalent de -MMD, c'est
-include $(OBJECTS:.o=.d)
.cpp.o:
$(CXX) -MM $(CFLAGS) $< > $(@:.o=.d)
$(CXX) -c $(CFLAGS) $(CXXFLAGS) -o $@ $<
(La seule chose a laquelle il faut faire attention, c'est introduire
explicitement les dependances sur les fichiers generes pour eviter que la
compil d'un fichier foire parce qu'un fichier genere n'est pas fait).
Marc Espie
Jean-Marc Bourguet <j...@bourguet.org> wrote:
>Fabien LE LEZ <gram...@gramster.com> writes:
>
>> On Mon, 23 Nov 2009 01:14:06 -0800 (PST), James Kanze
>> <james...@gmail.com>:
>>
>> >C'est tout � fait possible de faire quelque chose du genre avec GNU
>> >make,
>>
>> Comment fait-on, avec make, pour g�n�rer automatiquement les
>> d�pendances ? Si je ne m'abuse, make tout seul ne sait pas de quels .h
>> un .cpp d�pend.
>
>Tous les compilateurs que j'utilise ont des flags du genre -M? de GCC, qui
>permettent de recuperer l'info. Il suffit d'inclure le resultat dans le
>Makefile (ce qui suppose un make qui permet l'inclusion sans erreur si le
>fichier n'existe pas, comme GNU make).
Mais t'as toujours un petit probleme cote info-a-jour: faut faire tourner
gcc -M pour fabriquer le fichier en question, ce qui se fait avec un bout
de makefile. Mais une fois que ca a change, ben faut relancer make... avec
les bonnes dependances.
C'est une des multiples limitations de make, gnu-make n'etant pas mieux que
les autres (etant plutot pire cote documentation qui oublie de dire ce qui
est specifique a gnu-make, et ce qui est standard).
Il y a quelques tentatives de ci, de la, pour faire mieux, mais rien de
vraiment concluant dans mon experience...
Jean-Marc Bourguet
> Mais t'as toujours un petit probleme cote info-a-jour: faut faire tourner
> gcc -M pour fabriquer le fichier en question, ce qui se fait avec un bout
> de makefile. Mais une fois que ca a change, ben faut relancer make... avec
> les bonnes dependances.
Si je ne me trompe pas, les dependances sont invalidees exactement dans les
memes circonstances que le fichier objet -- du moins tant qu'on s'en tient
a la logique de make de se baser sur les dates.
> C'est une des multiples limitations de make, gnu-make n'etant pas mieux que
> les autres (etant plutot pire cote documentation qui oublie de dire ce qui
> est specifique a gnu-make, et ce qui est standard).
>
> Il y a quelques tentatives de ci, de la, pour faire mieux, mais rien de
> vraiment concluant dans mon experience...
clearmake (mais avec tous les avantages et les inconveniants de clearcase)
tant qu'on n'a pas de fichier qui peuvent etre mis a jour correctement de
plusieurs manieres (la gestion historique des templates de Sun CC par
exemple posait probleme).
Marc Espie
Jean-Marc Bourguet <j...@bourguet.org> wrote:
>es...@lain.home (Marc Espie) writes:
>
>> Mais t'as toujours un petit probleme cote info-a-jour: faut faire tourner
>> gcc -M pour fabriquer le fichier en question, ce qui se fait avec un bout
>> de makefile. Mais une fois que ca a change, ben faut relancer make... avec
>> les bonnes dependances.
>
>Si je ne me trompe pas, les dependances sont invalidees exactement dans les
>memes circonstances que le fichier objet -- du moins tant qu'on s'en tient
>a la logique de make de se baser sur les dates.
>
>> C'est une des multiples limitations de make, gnu-make n'etant pas mieux que
>> les autres (etant plutot pire cote documentation qui oublie de dire ce qui
>> est specifique a gnu-make, et ce qui est standard).
>>
>> Il y a quelques tentatives de ci, de la, pour faire mieux, mais rien de
>> vraiment concluant dans mon experience...
>
>clearmake (mais avec tous les avantages et les inconveniants de clearcase)
>tant qu'on n'a pas de fichier qui peuvent etre mis a jour correctement de
>plusieurs manieres (la gestion historique des templates de Sun CC par
>exemple posait probleme).
Revenons quand meme a la question de depart: le posteur initial voulait un truc
simple, et qui marche... de quelque facon qu'on y regarde, make ne remplit
pas ce cahier des charges. Deja, c'est pas tres simple, surtout pour du C++,
mais surtout, si ca reste simple, ca ne marche pas (bien), et si ca ne reste
pas simple, ca ne marche quand meme pas parfaitement...
TSalm
Si tu entends par "ￜa ne marche pas bien", que ￜa oblige ￜ avoir une faￜon
d'organiser ses sources qui soit restreinte, ï¿œa m'irait parfaitement bien.
Concernant mon organisation, c'est celle d'un dï¿œbutant que je suis, et qui
me convient pas mal jusqu'ici :
- j'ai une racine, appelont la src/
- quand je fait un include avec des doubles-quotes (#include
"doss1/doss2/mon_fichier.hpp"), il est dans "src/doss1/doss2/"
- si le fichier .hpp dont mon executable dï¿œpends a un .cpp (mï¿œme nom),
alors il faut gï¿œnï¿œrer ce .o et l'inclure lors du "linkage" de l'executable
- sur chaque executable ￜ gￜnￜrer, on peut individuellement passer des
paramￜtres de compilation. Ceci pour indiquer oￜ chercher les entￜtes et
les librairies statiques.
Ca n'existe pas ce genre du truc? C'est plus compliquￜ que je le crois ?
Marc Espie
>Le Mon, 23 Nov 2009 16:30:40 +0100, Marc Espie <es...@lain.home> a �crit:
>d'organiser ses sources qui soit restreinte, �a m'irait parfaitement bien.
>
>Concernant mon organisation, c'est celle d'un d�butant que je suis, et qui
>- j'ai une racine, appelont la src/
>- quand je fait un include avec des doubles-quotes (#include
>"doss1/doss2/mon_fichier.hpp"), il est dans "src/doss1/doss2/"
>alors il faut g�n�rer ce .o et l'inclure lors du "linkage" de l'executable
>- sur chaque executable � g�n�rer, on peut individuellement passer des
>param�tres de compilation. Ceci pour indiquer o� chercher les ent�tes et
>les librairies statiques.
>
>Ca n'existe pas ce genre du truc? C'est plus compliqu� que je le crois ?
C'est pas si simple que ca dans certains cas.
Vu ce que tu veux, tu devrais sans doute jeter un oeil a cmake. Ca fait un
gros bout de ce que tu veux, en cachant tous les details scabreux dans un
coin...
James Kanze
> In article <pxbtywlbgav....@news.bourguet.org>,
> Jean-Marc Bourguet <j...@bourguet.org> wrote:
> >Fabien LE LEZ <grams...@gramster.com> writes:
> >> On Mon, 23 Nov 2009 01:14:06 -0800 (PST), James Kanze
> >> <james.ka...@gmail.com>:
> >> >C'est tout à fait possible de faire quelque chose du genre
> >> >avec GNU make,
> >> Comment fait-on, avec make, pour générer automatiquement
> >> les dépendances ? Si je ne m'abuse, make tout seul ne sait
> >> pas de quels .h un .cpp dépend.
> >Tous les compilateurs que j'utilise ont des flags du genre
> >-M? de GCC, qui permettent de recuperer l'info. Il suffit
> >d'inclure le resultat dans le Makefile (ce qui suppose un
> >make qui permet l'inclusion sans erreur si le fichier
> >n'existe pas, comme GNU make).
Et même ceux qui ne l'ont pas, comme VC++, ont une option pour
obtenir la sortie du préprocesseur, avec ses #line, etc. Qu'on
passe à un script approprié, et le tour est joué.
> Mais t'as toujours un petit probleme cote info-a-jour: faut
> faire tourner gcc -M pour fabriquer le fichier en question, ce
> qui se fait avec un bout de makefile. Mais une fois que ca a
> change, ben faut relancer make... avec les bonnes dependances.
Il y a deux options : ou bien, tu as un cible spécial, depends,
qui génère les fichiers qui convienent quand on l'invoque, ou
bien, on le fait automatiquement chaque fois qu'on invoque make.
Le seul problème que j'ai jamais eu à cet égard, c'est quand
j'ai supprimé un en-tête. Et que make me disait qu'il ne
trouvait pas le fichier, et qu'il en avait besoin pour générer
ces fichiers de dépendance. Dans mon cas, un coup de make clean
suffisait, mais si on craint réelement les temps de compilation
qui s'en suivent, on pourrait bien concevoir un cible spécial
qui regénère les dependances, sans tenir compte de celles qui
existent. (L'inclusion du fichier avec les dépendences dépend,
évidemment, du cible ; on ne les inclut pas lors d'un make
clean, par exemple.)
> C'est une des multiples limitations de make, gnu-make n'etant
> pas mieux que les autres (etant plutot pire cote documentation
> qui oublie de dire ce qui est specifique a gnu-make, et ce qui
> est standard).
Quel standard ? Autant que je sache, il n'y a pas de norme de
make, et le sous-ensemble commun à tous les make est tellement
petit que d'être inutilisable. Dans l'ensemble, j'ai trouvé la
documentation de GNU make plutôt bon, au moins en ce qui
concerne les plateformes Unix. Les seules faiblesses que je lui
reconnaît, c'est l'organisation, que le rend parfois difficile à
trouver l'information voulue, et les explications de comment ça
fonctionne dans les environements autres qu'Unix. (Où, par
exemple, les chemins d'accès ont souvent des blancs, et prèsque
toujours un ':'. Et qu'il n'y a pas vraiment un shell standard
non plus. N'empêche qu'il fonctionne, que je m'en sers, et que
je suis même en train de l'écrire ce qu'il faut pour qu'il
utilise les dépendences et les règles de compilation du Visual
Studio.)
> Il y a quelques tentatives de ci, de la, pour faire mieux,
> mais rien de vraiment concluant dans mon experience...
Une partie du problème, je crois, c'est qu'ils veulent toujours
faire trop. Par exemple, je n'ai jamais trouvé un outil autre
que le compilateur qui arrive à déterminer correctement les
dépendences du point de vue du compilateur. (Jam, par exemple,
échoue complètement sur mes:
#include GB_dependentInclude(syst,Toto.hh)
qui include soit syst-posix/Toto.hh, soit syst-windows/Toto.hh,
selon le système sur lequel on se trouve.)
Que GNU make ait beaucoup de problèmes, j'en conviens, à
commencer par un grammaire basé sur le make initial. N'empêche
qu'il offre des possibilités de programmation de peu d'autres
outils, et que jusqu'ici, je n'ai pas vue d'autre alternatif qui
marche. (Sans oublier que pour moi, c'était mon introduction à
la programmation functionnelle.)
--
James Kanze
Marc Espie
James Kanze <james...@gmail.com> wrote:
>Quel standard�? Autant que je sache, il n'y a pas de norme de
>petit que d'�tre inutilisable. Dans l'ensemble, j'ai trouv� la
>documentation de GNU make plut�t bon, au moins en ce qui
>concerne les plateformes Unix.
Tu sais mal. Il faudrait te mettre a jour. make fait partie de POSIX, tu peux
par exemple trouver sa documentation dans Single Unix d'opengroup.
Le sous-ensemble commun a tous les make *est* utilisable. Tu y trouves les
variables, y compris les variables magiques telles que $@, les dependances,
les suffix rules.
Meme des fonctionnalites sympathiques telles que
make VAR=value
(qui override la valeur specifiee dans le Makefile) sont normalises.
C'est parfaitement possible de faire des choses tres raisonnables avec
(d'ailleurs une proportion non negligeable de logiciels savent compiler
avec plusieurs make).
... mais le fait que tu ne saches pas qu'il y a une norme, et quelles sont
les extensions supportees par tel ou tel make montre qu'il y a un souci
dans la doc de gnu-make...
Jean-Marc Bourguet
> Tu sais mal. Il faudrait te mettre a jour. make fait partie de POSIX, tu
> peux par exemple trouver sa documentation dans Single Unix d'opengroup.
>
> Le sous-ensemble commun a tous les make *est* utilisable.
Desole, de mon point de vue, l'absence d'include le rend inutilisable sans
generation (semi-)automatique des Makefiles eux-memes.
Senhon
"TSalm" <ts...@free.fr> a ï¿œcrit dans le message de groupe de discussion :
op.u3u1ytmak9rspk@papillon...
> Le Mon, 23 Nov 2009 16:30:40 +0100, Marc Espie <es...@lain.home> a ï¿œcrit:
>
> me convient pas mal jusqu'ici :
> - j'ai une racine, appelont la src/
> - quand je fait un include avec des doubles-quotes (#include
> "doss1/doss2/mon_fichier.hpp"), il est dans "src/doss1/doss2/"
> - si le fichier .hpp dont mon executable dï¿œpends a un .cpp (mï¿œme nom),
> alors il faut gï¿œnï¿œrer ce .o et l'inclure lors du "linkage" de l'executable
> - sur chaque executable ￜ gￜnￜrer, on peut individuellement passer des
> paramￜtres de compilation. Ceci pour indiquer oￜ chercher les entￜtes et
> les librairies statiques.
Dans ce genre de cas, je refais une compilation complï¿œte de l'application.
Si l'utilisation de make te permet d'ï¿œconomiser du temps lors de la
compilation, alors son usage est indiquￜ, sinon, pour de simple utilitaire
cela ne se justifie pas. D'autant plus quand les rï¿œgles de dï¿œpendance ne
sont pas clairement ï¿œtablies.
TSalm
Vu qu'il semble qu'il faut en passer par lￜ, je vais dￜjￜ commencer par
apprendre les Makefile.
>> Le 23/11/2009 12:58, Fabien LE LEZ a ï¿œcrit :
>> > On Mon, 23 Nov 2009 01:14:06 -0800 (PST), James Kanze
>> > <james...@gmail.com>:
>> >
>> >> C'est tout ￜ fait possible de faire quelque chose du genre avec GNU
>> >> make,
>> >
>> > Comment fait-on, avec make, pour gï¿œnï¿œrer automatiquement les
>> > dï¿œpendances ? Si je ne m'abuse, make tout seul ne sait pas de quels .h
>> > un .cpp dï¿œpend.
>>
>> Non, en effet. Il faut utiliser l'option -MM du prï¿œprocesseur de gcc.
>> Mais
>> c'est facile d'inclure la commande dans le Makefile :
>>
>> Par exemple :
>>
>> #-----8<-----------------------------
>> depend:
>> gcc -MM *.cpp > dependencies.mk
>>
>> # DEPENDANCES
>> -include dependencies.mk
>> #-----8<-----------------------------
>>
>> et un "make depend" gï¿œnï¿œre les dï¿œpendances.
>
> Je refais automatiquement la dependance avec l'objet. Ca evite de devoir
> se poser des questions quand a la necessite de faire un make depend.
> Donc
> pour gcc
>
> CXXFLAGS=-MMD
> -include $(OBJECTS:.o=.d)
>
> pour les compilateurs sans equivalent de -MMD, c'est
>
> -include $(OBJECTS:.o=.d)
> .cpp.o:
> $(CXX) -MM $(CFLAGS) $< > $(@:.o=.d)
> $(CXX) -c $(CFLAGS) $(CXXFLAGS) -o $@ $<
>
> (La seule chose a laquelle il faut faire attention, c'est introduire
> explicitement les dependances sur les fichiers generes pour eviter que la
> compil d'un fichier foire parce qu'un fichier genere n'est pas fait).
>
> A+
>
--
Utilisant le client e-mail rï¿œvolutionnaire d'Opera :
http://www.opera.com/mail/
James Kanze
> In article
> James Kanze <james.ka...@gmail.com> wrote:
> >Quel standard ? Autant que je sache, il n'y a pas de norme de
> >make, et le sous-ensemble commun à tous les make est
> >tellement petit que d'être inutilisable. Dans l'ensemble,
> >j'ai trouvé la documentation de GNU make plutôt bon, au moins
> >en ce qui concerne les plateformes Unix.
> Tu sais mal. Il faudrait te mettre a jour. make fait partie de
> POSIX, tu peux par exemple trouver sa documentation dans
> Single Unix d'opengroup.
En effet. Je ne sais pas pourquoi je croyais que ce n'était pas
le cas. Je sais que dans la passée (assez distante, je l'avoue),
je me suis battu avec les variations dans les makes d'un Unix à
l'autre, et que je me suis resigné à l'utilisation de GNU make,
étant donné qu'il était disponible sur toutes les plateformes (y
compris MS-DOS), et qu'il était toujours compatible avec
lui-même (à peu près).
> Le sous-ensemble commun a tous les make *est* utilisable. Tu y
> trouves les variables, y compris les variables magiques telles
> que $@, les dependances, les suffix rules.
Depuis le temps, j'utilise beaucoup plus de GNU make. Pour être
réelement utilisable, au minimum, il faut bien include, et
quelque chose pour faire des conditionnels. Dans mes fichiers
make d'aujourd'hui, je me sers de bien plus, au point qu'il me
faut même la version 3.81 de make, avec eval. (Du coup, je nomme
mes fichiers make GNUmakefile, de façon à ce que d'autres make
n'essaient même pas à les lire.)
> Meme des fonctionnalites sympathiques telles que
> make VAR=value
> (qui override la valeur specifiee dans le Makefile) sont
> normalises.
> C'est parfaitement possible de faire des choses tres
> raisonnables avec (d'ailleurs une proportion non negligeable
> de logiciels savent compiler avec plusieurs make).
> ... mais le fait que tu ne saches pas qu'il y a une norme, et
> quelles sont les extensions supportees par tel ou tel make
> montre qu'il y a un souci dans la doc de gnu-make...
J'ajoute ça comme défaut dans la documentation, oui. Qu'il n'y a
pas de référence à la norme (sauf, je viens de voir, dans
l'introduction), et pas d'indication ce qui est extension, et ce
qui ne l'est pas. (Il y a bien des passages où la documentation
par « d'autres make ». Mais ils sont en général assez vagues, et
ce n'est jamais clair quels autres make.)
De l'autre côté, on peut considérer GNU make quelque chose de
différent de Posix make : il peut exécuter les fichiers Posix
make, mais un peu comme F# peut exécuter du OCaml : sans
prétendre à être un Posix make pûr et dur. Alors, si tu veux
écrire GNU make, tu lis le manuel de GNU make, et si tu veux
écrire du Posix make, tu lis la norme Posix.
--
James Kanze
James Kanze
> es...@lain.home (Marc Espie) writes:
> > Tu sais mal. Il faudrait te mettre a jour. make fait partie
> > de POSIX, tu peux par exemple trouver sa documentation dans
> > Single Unix d'opengroup.
> > Le sous-ensemble commun a tous les make *est* utilisable.
> Desole, de mon point de vue, l'absence d'include le rend
> inutilisable sans generation (semi-)automatique des Makefiles
> eux-memes.
Et l'absense des conditionnels rend son utilisation difficile
dans des environements multi-plateforme. (Bien que je suppose
qu'avec include, on pourrait implémenter certains conditionnels
en utilisant un macro dans le nom d'un fichier qu'on inclut.)
--
Jame Kanze
Marc Espie
James Kanze <james...@gmail.com> wrote:
>J'ajoute �a comme d�faut dans la documentation, oui. Qu'il n'y a
>pas de r�f�rence � la norme (sauf, je viens de voir, dans
>l'introduction), et pas d'indication ce qui est extension, et ce
>par ��d'autres make��. Mais ils sont en g�n�ral assez vagues, et
>ce n'est jamais clair quels autres make.)
>De l'autre c�t�, on peut consid�rer GNU make quelque chose de
>diff�rent de Posix make�: il peut ex�cuter les fichiers Posix
>make, mais un peu comme F# peut ex�cuter du OCaml�: sans
>pr�tendre � �tre un Posix make p�r et dur. Alors, si tu veux
>�crire GNU make, tu lis le manuel de GNU make, et si tu veux
>�crire du Posix make, tu lis la norme Posix.
Mouais... ca tient seulement a moitie la route. Deja, il faut savoir
qu'il existe d'autres choses. Ensuite je corrige tres regulierement des
choses qui sont tres mineures dans des Makefile qui ne passeraient QUE
avec gnu-make, juste pour une merdouille inutile.
Ensuite, si tu te places dans une optique de "GNU uber alles" qui est
malheureusement un peu le cas du cote FSF hardcore (avec le classique:
si vous etes sur un autre Unix, commencez par installer les outils GNU,
vous serez tranquilles), ben c'est un peu la guerre pour continuer a
defendre des alternatives viables (surtout que l'epoque ou tu avais des
outils tres moyens sur d'autres Unix en dehors de GNU est quand meme tres
revolue...)
Marc Espie
James Kanze <james...@gmail.com> wrote:
>On Nov 24, 10:32 am, Jean-Marc Bourguet <j...@bourguet.org> wrote:
>> es...@lain.home (Marc Espie) writes:
>> > Tu sais mal. Il faudrait te mettre a jour. make fait partie
>> > de POSIX, tu peux par exemple trouver sa documentation dans
>> > Single Unix d'opengroup.
>
>> > Le sous-ensemble commun a tous les make *est* utilisable.
>
>> Desole, de mon point de vue, l'absence d'include le rend
>> inutilisable sans generation (semi-)automatique des Makefiles
>> eux-memes.
>
>Et l'absense des conditionnels rend son utilisation difficile
>dans des environements multi-plateforme. (Bien que je suppose
>en utilisant un macro dans le nom d'un fichier qu'on inclut.)
En pratique, la grande majorite des make supportent les include system V, a la
include "nom de fichier"
y compris avec des noms de variables dans le nom.
ce qui ne marche generalement pas, c'est les inclusions "au cas ou", ou il
existe plusieurs syntaxes differentes (-include, sinclude) qui dependent du
make considere.
James Kanze
> In article
> James Kanze <james.ka...@gmail.com> wrote:
> >J'ajoute ça comme défaut dans la documentation, oui. Qu'il
> >n'y a pas de référence à la norme (sauf, je viens de voir,
> >dans l'introduction), et pas d'indication ce qui est
> >extension, et ce qui ne l'est pas. (Il y a bien des passages
> >où la documentation par « d'autres make ». Mais ils sont en
> >général assez vagues, et ce n'est jamais clair quels autres
> >make.) De l'autre côté, on peut considérer GNU make quelque
> >chose de différent de Posix make : il peut exécuter les
> >fichiers Posix make, mais un peu comme F# peut exécuter du
> >OCaml : sans prétendre à être un Posix make pûr et dur.
> >Alors, si tu veux écrire GNU make, tu lis le manuel de GNU
> >make, et si tu veux écrire du Posix make, tu lis la norme
> >Posix.
> Mouais... ca tient seulement a moitie la route. Deja, il faut
> savoir qu'il existe d'autres choses.
C'est vrai. Mais sur mes machines, si j'invoque gmake, j'ai GNU
make ; si je n'invoque que make, j'ai bien quelque chose
d'autre (où la plus souvent, actuellement, « command not
found ». Il n'y a que Linux où il doit y avoir un problème,
ou...
Mais au fond, tu as raison, et une bonne suggestion pour une
amélioration : si le nom de l'invocation ne commence pas par un
'g', ou le fichier de make trouvé n'est pas GNUmakefile, il
faudrait qu'il supprime tous les extensions.
> Ensuite je corrige tres regulierement des choses qui sont tres
> mineures dans des Makefile qui ne passeraient QUE avec
> gnu-make, juste pour une merdouille inutile.
C'est vrai que si tu ne veux pas GNU make, il vaut mieux ne pas
l'utiliser:-). (Mais c'est un problème avec beaucoup des outils
GNU. Ils ont des extensions, parfois pour rien, mais souvent
bien utile. Alors, quelqu'un les installe à un endroit où ils
remplacent les versions standard, plutôt que d'être un
alternatif, pour les cas où on veut les extensions.)
> Ensuite, si tu te places dans une optique de "GNU uber alles"
Ce n'est pas mon cas, je crois que tu le sais:-).
> qui est malheureusement un peu le cas du cote FSF hardcore
> (avec le classique: si vous etes sur un autre Unix, commencez
> par installer les outils GNU, vous serez tranquilles), ben
> c'est un peu la guerre pour continuer a defendre des
> alternatives viables (surtout que l'epoque ou tu avais des
> outils tres moyens sur d'autres Unix en dehors de GNU est
> quand meme tres revolue...)
Dans le cas de make, je me suis servi de GNU make au départ pour
des raisons de compatibilité, bien avant qu'on parlait de Posix,
et que les make des differents Unix étaient tous différents
(sans parler du make de MS-DOS). C'était simplement la solution
la plus simple. Ensuite, il y a peu, je me suis attaqué à
refaire mon système de build. Après quelques expériences avec
jam (qui ne sait pas gérer les dépendences tout seul, mais qui à
l'encontre de make, croit le savoir), je me suis retourné à mon
bon vieux GNU make, où j'ai trouvé un langage fonctionnel Turing
complete. Du coup, j'y ai écrit le système de build -- ce n'est
vraiment plus du make, mais quelque chose de bien plus complex,
écrit par moi-même dans le langage GNU make. Mais évidemment, il
ne marche que si tu as ce langage sur ta machine. (Actuellement,
je n'ai pratiquement accès qu'aux machines Windows, où je
l'invoque mingw32-make. L'autre alternatif serait nmake, mais il
ne comprend pas mon programme. Sans être Posix-conforme pour
autant:-).)
Enfin, j'accepte ton critique qu'invoquer make, et n'avoir que
GNU make, ce n'est pas très bien, parce que GNU make, ce n'est
pas make. Mais c'est un outil fort bien quand même. Dans un
domain où des outils bien manquent énormement.
--
James Kanze
Michael Doubez
[snip]
> Dans le cas de make, je me suis servi de GNU make au départ pour
> des raisons de compatibilité, bien avant qu'on parlait de Posix,
> et que les make des differents Unix étaient tous différents
> (sans parler du make de MS-DOS). C'était simplement la solution
> la plus simple. Ensuite, il y a peu, je me suis attaqué à
> refaire mon système de build. Après quelques expériences avec
> jam (qui ne sait pas gérer les dépendences tout seul, mais qui à
> l'encontre de make, croit le savoir), je me suis retourné à mon
> bon vieux GNU make, où j'ai trouvé un langage fonctionnel Turing
> complete. Du coup, j'y ai écrit le système de build -- ce n'est
> vraiment plus du make, mais quelque chose de bien plus complex,
> écrit par moi-même dans le langage GNU make. Mais évidemment, il
> ne marche que si tu as ce langage sur ta machine. (Actuellement,
> je n'ai pratiquement accès qu'aux machines Windows, où je
> l'invoque mingw32-make. L'autre alternatif serait nmake, mais il
> ne comprend pas mon programme. Sans être Posix-conforme pour
> autant:-).)
Il y a aussi les outils gnuwin32 (dont make) qui permettent d'avoir
les outils classics en win32 natif. Je les utilise pour compléter mon
install de MinGW avec sed, cat, wget ... et même les expression [ -
f ... ]. Le seul conflit que j'ai trouvé avec Windows est avec echo et
find.
> Enfin, j'accepte ton critique qu'invoquer make, et n'avoir que
> GNU make, ce n'est pas très bien, parce que GNU make, ce n'est
> pas make. Mais c'est un outil fort bien quand même. Dans un
> domain où des outils bien manquent énormement.
Concernant la standardisation type unix98, c'est bien d'avoir un
standard mais mon impression est que, en général, ils ont pris le plus
petit dénominateur commun.
Il y a des extensions gnu qui simplifient vraiment la vie comme
l'option -i de (gnu)sed qui permet de modifier directement le fichier.
--
Michael
James Kanze
> On 25 nov, 18:16, James Kanze <james.ka...@gmail.com> wrote:
> [snip]
> d'avoir les outils classics en win32 natif. Je les utilise
> pour compléter mon install de MinGW avec sed, cat, wget ... et
> même les expression [ - f ... ]. Le seul conflit que j'ai
> trouvé avec Windows est avec echo et find.
En effet.
En général, les ports plus ou moins complets des outils Unix
(CygWin, MinGW) s'integrent mal dans Windows, et posent des
problèmes quand on veut se servir aussi des programmes Windows.
Tandis que les ports plus ou moins indépendants de chaque outil
n'ont pas ce problème.
> > Enfin, j'accepte ton critique qu'invoquer make, et n'avoir que
> > GNU make, ce n'est pas très bien, parce que GNU make, ce n'est
> > pas make. Mais c'est un outil fort bien quand même. Dans un
> > domain où des outils bien manquent énormement.
> Concernant la standardisation type unix98, c'est bien d'avoir
> un standard mais mon impression est que, en général, ils ont
> pris le plus petit dénominateur commun.
Ils ont normalisé la pratique existante ; ce que font les Unix
existants. C'est normalement la rôle d'une normalisation.
> Il y a des extensions gnu qui simplifient vraiment la vie
> comme l'option -i de (gnu)sed qui permet de modifier
> directement le fichier.
Modifier directement le fichier va à l'encontre de la
philosophie de base des programmes filtre:-). Mais ça fait
penser que j'ai encore du vieux code C quelque part pour
supporter un certain nombre d'options standard, dont :
-o <fichier>
Si <fichier> c'est un nom de fichier, rédiriger les
sorties vers ce fichier. Si c'est le nom d'un
répertoire, créer un nouveau fichier de sortie pour
chaque fichier en entrée dans ce répertoire, avec le nom
du fichier en entrée. Et si c'est un nom avec des
métacaractères, j'avais une heuristique pour en générer
un nom de fichier en sortie à partir du nom de fichier
en entrée.
-O Pour chaque fichier en entrée, rédiriger les sorties
vers un fichier temporaire, qui vient remplacer le
fichier en entrée s'il n'y a pas d'erreur.
--
James Kanze
Marc Espie
Michael Doubez <michael...@free.fr> wrote:
>On 25 nov, 18:16, James Kanze <james.ka...@gmail.com> wrote:
>[snip]
>> des raisons de compatibilit�, bien avant qu'on parlait de Posix,
>> et que les make des differents Unix �taient tous diff�rents
>> (sans parler du make de MS-DOS). C'�tait simplement la solution
>> la plus simple. Ensuite, il y a peu, je me suis attaqu� �
>> refaire mon syst�me de build. �Apr�s quelques exp�riences avec
>> jam (qui ne sait pas g�rer les d�pendences tout seul, mais qui �
>> l'encontre de make, croit le savoir), je me suis retourn� � mon
>> bon vieux GNU make, o� j'ai trouv� un langage fonctionnel Turing
>> complete. Du coup, j'y ai �crit le syst�me de build�-- ce n'est
>> vraiment plus du make, mais quelque chose de bien plus complex,
>> ne marche que si tu as ce langage sur ta machine. (Actuellement,
>> l'invoque mingw32-make. L'autre alternatif serait nmake, mais il
>> autant:-).)
>
>Il y a aussi les outils gnuwin32 (dont make) qui permettent d'avoir
>install de MinGW avec sed, cat, wget ... et m�me les expression [ -
>f ... ]. Le seul conflit que j'ai trouv� avec Windows est avec echo et
>find.
>> Enfin, j'accepte ton critique qu'invoquer make, et n'avoir que
>> GNU make, ce n'est pas tr�s bien, parce que GNU make, ce n'est
>> pas make. Mais c'est un outil fort bien quand m�me. Dans un
>> domain o� des outils bien manquent �normement.
>Concernant la standardisation type unix98, c'est bien d'avoir un
>standard mais mon impression est que, en g�n�ral, ils ont pris le plus
>petit d�nominateur commun.
>Il y a des extensions gnu qui simplifient vraiment la vie comme
>l'option -i de (gnu)sed qui permet de modifier directement le fichier.
Oh pitie. C'est fait pour les boulets, sed -i.
Parce que mv file file.old && sed <file.old >file
c'est pas sorcier.
Le principe d'Unix, c'est d'avoir des petits outils qui se comportent
bien entre eux.
L'optique gnu, au depart, c'est "on est parano cote copyright, donc on
va prendre le contrepied de ce qui existe". Ensuite "on fait comme le
parti communiste et on reecrit l'histoire. Comme ce qu'on fait c'est mieux
d'un point de vue ethique, ca doit forcement etre mieux du point de vue
technique". Et au final "unix n'existe plus, il n'y a plus que GNU Unix,
alias hurd".
Okay, je caricature en forcant le trait, mais il y a franchement un peu
de ca, et il y a des idees gnu qui sont nocives au final
(le coup de la glibc qui "accepte" des pointeurs nuls comme chaines de
caracteres valides, par exemple, ou encore cette idee saugrenue que les
pages de man, c'est du passe, et que info c'est mieux)...
Mickaël Wolff
> Oh pitie. C'est fait pour les boulets, sed -i.
>
> Parce que mv file file.old && sed <file.old >file
> c'est pas sorcier.
Faut quand m�me pas pousser. Je crois que le boulet c'est celui qui
refuse d'utiliser une fonctionnalit� qui permette de se simplifier la
vie. Tu n'utilises pas les flags x ou j de tar ? Le flag i de GNU sed a
au moins l'avantage d'�conomiser mes petits doigts boudin�s par le chac
des touches (�a fait mal un clavier � force).
> Le principe d'Unix, c'est d'avoir des petits outils qui se comportent
> bien entre eux.
Je suis bien d'accord sur la philosophie Unix, mais en quoi le flag i
de GNU sed contrevient � cette r�gle ?
> L'optique gnu, au depart, c'est "on est parano cote copyright, donc on
> va prendre le contrepied de ce qui existe". Ensuite "on fait comme le
> parti communiste et on reecrit l'histoire. Comme ce qu'on fait c'est mieux
> d'un point de vue ethique, ca doit forcement etre mieux du point de vue
> technique". Et au final "unix n'existe plus, il n'y a plus que GNU Unix,
> alias hurd".
Je voulais parler des autotools pour savoir ce que vous en pensiez
tous, et surtout si vous l'utilisiez. Mais vu ta r�action, j'ai peur que
�a ne tourne au Troll bien velu :'(
M�me si c'est orthogonal � fclc++, je suis int�ress� par vos avis. Au
pire on sautera dans fr.comp.developpement si la discussion g�ne la
majorit�.
> Okay, je caricature en forcant le trait, mais il y a franchement un peu
> de ca, et il y a des idees gnu qui sont nocives au final
> (le coup de la glibc qui "accepte" des pointeurs nuls comme chaines de
> caracteres valides, par exemple, ou encore cette idee saugrenue que les
> pages de man, c'est du passe, et que info c'est mieux)...
Sur ces points je suis largement d'accord avec toi. Surtout que c'est
l'enfer de naviguer dans infos (d�sol�, je suis un Vimer).
--
Micka�l Wolff aka Lupus Michaelis
http://lupusmic.org
Michael Doubez
> In article <7e4eb714-457f-4f2e-beb0-07c3ae175...@g26g2000yqe.googlegroups.com>,
> Michael Doubez <michael.dou...@free.fr> wrote:
> >On 25 nov, 18:16, James Kanze <james.ka...@gmail.com> wrote:
[snip]
> >> pas make. Mais c'est un outil fort bien quand même. Dans un
> >> domain où des outils bien manquent énormement.
> >petit dénominateur commun.
> >Il y a des extensions gnu qui simplifient vraiment la vie comme
> >l'option -i de (gnu)sed qui permet de modifier directement le fichier.
>
> Oh pitie. C'est fait pour les boulets, sed -i.
La pitié ne me fait pas honte et j'assume mon status de boulet :)
Surtout quand ca me permet de n'embarquer qu'un seul programme.
> Parce que mv file file.old && sed <file.old >file
> c'est pas sorcier.
Et pourtant il y a une erreur pour avoir le même comportement ;)
mv file file.old && sed <file.old >file && rm file.old
Et qui bien sûre ne marche pas si j'ai les droit d'écriture sur le
fichier mais pas sur le directory; et en plus me pourri mon backup (à
moins de numéroter ensuite les nom de fichier ou utiliser un tmp avec
un nom de fichier unique ...).
> Le principe d'Unix, c'est d'avoir des petits outils qui se comportent
> bien entre eux.
Un programme aussi est composé d'élements qui se comportent bien entre
eux, il n'empèche que je préfère:
std::swap(a,b);
plutôt que
tmp = a;
a = b;
b = tmp;
> L'optique gnu, au depart, c'est "on est parano cote copyright, donc on
> va prendre le contrepied de ce qui existe".Ensuite "on fait comme le
> parti communiste et on reecrit l'histoire. Comme ce qu'on fait c'est mieux
> d'un point de vue ethique, ca doit forcement etre mieux du point de vue
> technique". Et au final "unix n'existe plus, il n'y a plus que GNU Unix,
> alias hurd".
AMHA ce n'est pas la démarche de Richard Stallman, au moins au début,
surtout quand il recodait les outils unix avec le même nom et en
suivant feature par feature l'évolution des outils UNIX (ULTRIX ?).
Et ce n'est pas l'idée de la GPL qui est basiquement qu'une personne
peut profiter d'un programme et le modifier à la condition qu'elle ne
bloque pas son évolution.
> Okay, je caricature en forcant le trait, mais il y a franchement un peu
> de ca, et il y a des idees gnu qui sont nocives au final
> (le coup de la glibc qui "accepte" des pointeurs nuls comme chaines de
> caracteres valides, par exemple, ou encore cette idee saugrenue que les
> pages de man, c'est du passe, et que info c'est mieux)...
Dans le cas de la glibc, je n'ai pas la norme sous le coude mais je ne
crois pas qu'elle impose une erreur. A vue de nez, ça doit être un
comportement indéfini donc traiter NULL comme une chaine valide n'est
pas si grave et conforme: je ne connais personne qui compte sur un
segfault de printf() pour détecter les chaines NULL.
Quand au man vs info ... c'est un détail. Je ne trouve pas le man de
gcc plus lisible que le info de make (et inversement ) :o)
--
Michael
Michael Doubez
> Marc Espie a écrit :
> Je voulais parler des autotools pour savoir ce que vous en pensiez
> ça ne tourne au Troll bien velu :'(
J'ai utiliser une fois les auto tools pour un projet. Je n'en ai pas
une experience mémorable à par de la frustration pour les
incompatibilités de version.
J'ai du faire quelques scripts m4 pour mon projet (principalement du
recyclage de scripts existant).
Je pense que c'est comme en C quand tu utilises des macros en
metalangage pour construire ton programme: tant que tu ne sors pas des
chemins battus, ça se passe bien.
Ce qui veut dire que ça se passe bien en général :)
> Même si c'est orthogonal à fclc++, je suis intéressé par vos avis. Au
> pire on sautera dans fr.comp.developpement si la discussion gêne la
> majorité.
Etant donné le traffic sur fclc++, la majorité est plutôt silencieuse.
--
Michael
Marc Espie
Micka�l Wolff <mickae...@laposte.net> wrote:
>Marc Espie a �crit :
>
>> Oh pitie. C'est fait pour les boulets, sed -i.
>>
>> Parce que mv file file.old && sed <file.old >file
>> c'est pas sorcier.
> Faut quand m�me pas pousser. Je crois que le boulet c'est celui qui
>refuse d'utiliser une fonctionnalit� qui permette de se simplifier la
>vie. Tu n'utilises pas les flags x ou j de tar ? Le flag i de GNU sed a
>au moins l'avantage d'�conomiser mes petits doigts boudin�s par le chac
>des touches (�a fait mal un clavier � force).
Non, je n'utilise pas le flag j de tar.
Ni le flag i de sed.
> Je suis bien d'accord sur la philosophie Unix, mais en quoi le flag i
>de GNU sed contrevient � cette r�gle ?
C'est pas standard.
> Je voulais parler des autotools pour savoir ce que vous en pensiez
>tous, et surtout si vous l'utilisiez. Mais vu ta r�action, j'ai peur que
>�a ne tourne au Troll bien velu :'(
Je pense enormement de mal des autotools. Typiquement, ces derniers temps
ils permettent surtout de verifier que ca compile sur plusieurs variations
de linux/i386... j'ai passe suffisamment de temps a corriger des tonnes de
bugs sur ceux-ci pour ne plus du tout les aimer (entre autres, des cons
qui utilisent sed -i dans un configure.ac...)
C'etait a priori une bonne idee, mais le resultat est dantesque. Il y a de
graves problems dans automake (l'idee d'avoir du make recursif qui fait
des trucs dans le repertoire courant, et dans des sous-repertoires) est
a vomir... l'implementation en est super-moche.
Le principal truc qui pose probleme, c'est de faire de la generation
automatique de fichiers style configure ou Makefile, en utilisant des
outils inadaptes (reecrire lisp en m4 ? mais bien sur !!!).
Desole, je suis en pause au milieu d'un cours, je retourne embeter mes
etudiants.
Marc Espie
Michael Doubez <michael...@free.fr> wrote:
>Dans le cas de la glibc, je n'ai pas la norme sous le coude mais je ne
>comportement ind�fini donc traiter NULL comme une chaine valide n'est
>pas si grave et conforme: je ne connais personne qui compte sur un
Par contre, je connais tres bien quelqu'un qui corrige regulierement
des segfault de programmes developpes sous Linux lorsqu'on veut les
faire tourner sous un autre Unix, segfaults de type
strcmp(NULL, a)...
James Kanze
> In article
> Michael Doubez <michael.dou...@free.fr> wrote:
[...]
> >Il y a des extensions gnu qui simplifient vraiment la vie
> >comme l'option -i de (gnu)sed qui permet de modifier
> >directement le fichier.
> Oh pitie. C'est fait pour les boulets, sed -i.
> Parce que mv file file.old && sed <file.old >file
> c'est pas sorcier.
Sauf que ça serait plutôt:
for x in *.files
do
sed -e 'whatever' $x > $x.new && mv $x.new $x
done
(Au moins si le -i est bien implémenté.)
Sans oublier que ed (ou ex) fait la même chose.
> Le principe d'Unix, c'est d'avoir des petits outils qui se
> comportent bien entre eux.
Au debut, le « petit », c'était primordial, vue la taille des
machines. Aujourd'hui, je le crois acceptable d'ajouter un peu
de fonctionalité supplémentaire si ça ajoute à la commodité.
> L'optique gnu, au depart, c'est "on est parano cote copyright,
> donc on va prendre le contrepied de ce qui existe". Ensuite
> "on fait comme le parti communiste et on reecrit l'histoire.
> Comme ce qu'on fait c'est mieux d'un point de vue ethique, ca
> doit forcement etre mieux du point de vue technique". Et au
> final "unix n'existe plus, il n'y a plus que GNU Unix, alias
> hurd".
> Okay, je caricature en forcant le trait, mais il y a
> franchement un peu de ca, et il y a des idees gnu qui sont
> nocives au final (le coup de la glibc qui "accepte" des
> pointeurs nuls comme chaines de caracteres valides, par
> exemple, ou encore cette idee saugrenue que les pages de man,
> c'est du passe, et que info c'est mieux)...
Dans l'ensemble, j'aurais tendance à être d'accord avec toi. Ce
qui ne veut pas dire que dans certains cas bien précis, les
extensions sont plutôt commode.
--
James Kanze
James Kanze
> On 26 nov, 14:03, es...@lain.home (Marc Espie) wrote:
> > In article <7e4eb714-457f-4f2e-beb0-07c3ae175...@g26g2000yqe.googlegroups.com>,
[...]
> > Parce que mv file file.old && sed <file.old >file c'est pas
> > sorcier.
> Et pourtant il y a une erreur pour avoir le même comportement
> ;) mv file file.old && sed <file.old >file && rm file.old
J'espère que ce n'est pas le comportement du -i. Sinon, c'est à
éviter. Comme j'ai dire ailleurs, il ne faut pas détruire
l'original si on rencontre une erreur lors de la transformation.
(Imagine ce qui se passe si la disque est à peu près plein, et
qu'il y a une erreur d'écriture après n'avoir transformé qu'un
tiers du fichier.)
[...]
> > Okay, je caricature en forcant le trait, mais il y a
> > franchement un peu de ca, et il y a des idees gnu qui sont
> > nocives au final (le coup de la glibc qui "accepte" des
> > pointeurs nuls comme chaines de caracteres valides, par
> > exemple, ou encore cette idee saugrenue que les pages de
> > man, c'est du passe, et que info c'est mieux)...
>
> Dans le cas de la glibc, je n'ai pas la norme sous le coude
> mais je ne crois pas qu'elle impose une erreur. A vue de nez,
> ça doit être un comportement indéfini donc traiter NULL comme
> une chaine valide n'est pas si grave et conforme: je ne
> connais personne qui compte sur un segfault de printf() pour
> détecter les chaines NULL.
Moi. Au moins, quand j'ai une erreur de programmation, je veux
le savoir le plus vite possible. Masquer les erreurs n'est
jamais un bon choix.
--
James Kanze
Michael Doubez
> On Nov 26, 2:49 pm, Michael Doubez <michael.dou...@free.fr> wrote:
>
> > On 26 nov, 14:03, es...@lain.home (Marc Espie) wrote:
> > > In article <7e4eb714-457f-4f2e-beb0-07c3ae175...@g26g2000yqe.googlegroups.com>,
>
> [...]
>
> > > Parce que mv file file.old && sed <file.old >file c'est pas
> > > sorcier.
> > Et pourtant il y a une erreur pour avoir le même comportement
> > ;) mv file file.old && sed <file.old >file && rm file.old
>
> J'espère que ce n'est pas le comportement du -i. Sinon, c'est à
> éviter. Comme j'ai dire ailleurs, il ne faut pas détruire
> l'original si on rencontre une erreur lors de la transformation.
> (Imagine ce qui se passe si la disque est à peu près plein, et
> qu'il y a une erreur d'écriture après n'avoir transformé qu'un
> tiers du fichier.)
J'espère que dans ce cas sed renvoit une erreur et le && n'est pas
executé.
Oui, il faut traiter le cas ou sed rate ou si il ne peut pas parser
l'expression.
> [...]
>
> > > Okay, je caricature en forcant le trait, mais il y a
> > > franchement un peu de ca, et il y a des idees gnu qui sont
> > > nocives au final (le coup de la glibc qui "accepte" des
> > > pointeurs nuls comme chaines de caracteres valides, par
> > > exemple, ou encore cette idee saugrenue que les pages de
> > > man, c'est du passe, et que info c'est mieux)...
>
> > Dans le cas de la glibc, je n'ai pas la norme sous le coude
> > mais je ne crois pas qu'elle impose une erreur. A vue de nez,
> > ça doit être un comportement indéfini donc traiter NULL comme
> > une chaine valide n'est pas si grave et conforme: je ne
> > connais personne qui compte sur un segfault de printf() pour
> > détecter les chaines NULL.
>
> Moi. Au moins, quand j'ai une erreur de programmation, je veux
> le savoir le plus vite possible. Masquer les erreurs n'est
> jamais un bon choix.
Je suis d'accord mais dans la mesure où le comportment est indéfini,
c'est AMA au codeur de mettre un assert() pour vérifier ses pré-
conditions.
Pour moi, ce serait comme si je ne testait pas si un pointeur est NULL
en me disant que de toutes façons ça fait un segfault si ça arrive.
--
Michael
James Kanze
> On 26 nov, 19:53, James Kanze <james.ka...@gmail.com> wrote:
> > On Nov 26, 2:49 pm, Michael Doubez <michael.dou...@free.fr> wrote:
> > > On 26 nov, 14:03, es...@lain.home (Marc Espie) wrote:
> > > > In article
> > > > <7e4eb714-457f-4f2e-beb0-07c3ae175...@g26g2000yqe.googlegroups.com>,
> > [...]
> > > > Parce que mv file file.old && sed <file.old >file c'est
> > > > pas sorcier.
> > > Et pourtant il y a une erreur pour avoir le même
> > > comportement ;) mv file file.old && sed <file.old >file &&
> > > rm file.old
> > J'espère que ce n'est pas le comportement du -i. Sinon,
> > c'est à éviter. Comme j'ai dire ailleurs, il ne faut pas
> > détruire l'original si on rencontre une erreur lors de la
> > transformation. (Imagine ce qui se passe si la disque est à
> > peu près plein, et qu'il y a une erreur d'écriture après
> > n'avoir transformé qu'un tiers du fichier.)
> J'espère que dans ce cas sed renvoit une erreur et le && n'est
> pas executé. Oui, il faut traiter le cas ou sed rate ou si il
> ne peut pas parser l'expression.
S'un programme ne renvoit pas une erreur lors d'une erreur
d'écriture, c'est bien une erreur dans le programme. Qu'il faut
absolument corriger. (Dans le cas de mon C++, c'est la classe
singleton ProgramStatus qui s'en occupe, quand on lui démande le
status de retour. C'est donc systèmatique. Mais même avant, en
C, je faisais bien un fflush(), avec une vérification du
résultat, avant de terminer.)
> > [...]
> > > > Okay, je caricature en forcant le trait, mais il y a
> > > > franchement un peu de ca, et il y a des idees gnu qui sont
> > > > nocives au final (le coup de la glibc qui "accepte" des
> > > > pointeurs nuls comme chaines de caracteres valides, par
> > > > exemple, ou encore cette idee saugrenue que les pages de
> > > > man, c'est du passe, et que info c'est mieux)...
> > > Dans le cas de la glibc, je n'ai pas la norme sous le
> > > coude mais je ne crois pas qu'elle impose une erreur. A
> > > vue de nez, ça doit être un comportement indéfini donc
> > > traiter NULL comme une chaine valide n'est pas si grave et
> > > conforme: je ne connais personne qui compte sur un
> > > segfault de printf() pour détecter les chaines NULL.
> > Moi. Au moins, quand j'ai une erreur de programmation, je
> > veux le savoir le plus vite possible. Masquer les erreurs
> > n'est jamais un bon choix.
> Je suis d'accord mais dans la mesure où le comportment est
> indéfini, c'est AMA au codeur de mettre un assert() pour
> vérifier ses pré- conditions.
Dans la mesure où c'est un comportement indéfini, c'est au
codeur de ne pas le faire. Si tous les codeurs étaient parfaits,
et ne faisaient jamais d'erreur, c'est égal ce que fait strxxx
dans ces cas-là. Autrement, il vaut mieux crasher le plus vite
possible en cas d'erreur.
Historiquement... Les tous premiers Unix s'arrangaient pour que
les 512 premiers octets soient accessibles en lecture (ils
n'avaient pas le choix avec les machines de l'époque) et
contenaient 0. Je me rappelle qu'effectivement, quand on a
introduit la mémoire virtuelle, on n'a pas mappé la page 0,
justement pour detecter ce genre d'erreur. Et du coup, pas mal
d'utilitaires de base ne fonctionnaient plus ; on a dû faire
marche en arrière jusqu'à ce ils soient corrigés. Mais c'était
au milieu des années 1980 ; depuis lors, j'espèrerais que ce
n'est plus un problème. (Je sais qu'on n'était pas les seuls à
rencontrer le problème, et que les sources « officielles », de
AT&T, ont été changées peu après.)
> Pour moi, ce serait comme si je ne testait pas si un pointeur
> est NULL en me disant que de toutes façons ça fait un segfault
> si ça arrive.
Ça dépend du contrat. En C++, en général, si je n'accepte pas
NULL, j'utilise une référence, non un pointeur. Et je ne teste
pas pour NULL.
--
James Kanze
Marc Espie
James Kanze <james...@gmail.com> wrote:
>Historiquement... Les tous premiers Unix s'arrangaient pour que
>les 512 premiers octets soient accessibles en lecture (ils
>contenaient 0. Je me rappelle qu'effectivement, quand on a
>justement pour detecter ce genre d'erreur. Et du coup, pas mal
>marche en arri�re jusqu'� ce ils soient corrig�s. Mais c'�tait
>au milieu des ann�es 1980�; depuis lors, j'esp�rerais que ce
>n'est plus un probl�me. (Je sais qu'on n'�tait pas les seuls �
>rencontrer le probl�me, et que les sources ��officielles��, de
>AT&T, ont �t� chang�es peu apr�s.)
Faudra que je retrouve (ou que tu fasses une recherche) sur un trou recent
de flash, qui correspond a une dereferencement du pointeur nul assez joli.
Oui, la page zero n'est pas mappee, mais si tu utilises le pointeur nul
pour faire p->tab[1024], en supposant que tab est un tableau de taille
variable niche a la fin de ta structure de donnees, tu peux eviter le segfault
et taper dans de la memoire valide... et ca fournit une classe d'exploit
assez joli (en l'occurrence, l'exploit flash en question est dependant du
processeur, mais pas de l'OS, et donc fonctionnait indifferemment sous
windows ou linux).
Michael Doubez
> On Nov 27, 8:43 am, Michael Doubez <michael.dou...@free.fr> wrote:
> > On 26 nov, 19:53, James Kanze <james.ka...@gmail.com> wrote:
> > > On Nov 26, 2:49 pm, Michael Doubez <michael.dou...@free.fr> wrote:
> > > > On 26 nov, 14:03, es...@lain.home (Marc Espie) wrote:
> > > > > Okay, je caricature en forcant le trait, mais il y a
> > > > > franchement un peu de ca, et il y a des idees gnu qui sont
> > > > > nocives au final (le coup de la glibc qui "accepte" des
> > > > > pointeurs nuls comme chaines de caracteres valides, par
> > > > > exemple, ou encore cette idee saugrenue que les pages de
> > > > > man, c'est du passe, et que info c'est mieux)...
> > > > Dans le cas de la glibc, je n'ai pas la norme sous le
> > > > coude mais je ne crois pas qu'elle impose une erreur. A
> > > > vue de nez, ça doit être un comportement indéfini donc
> > > > traiter NULL comme une chaine valide n'est pas si grave et
> > > > conforme: je ne connais personne qui compte sur un
> > > > segfault de printf() pour détecter les chaines NULL.
> > > Moi. Au moins, quand j'ai une erreur de programmation, je
> > > veux le savoir le plus vite possible. Masquer les erreurs
> > > n'est jamais un bon choix.
> > Je suis d'accord mais dans la mesure où le comportment est
> > indéfini, c'est AMA au codeur de mettre un assert() pour
> > vérifier ses pré- conditions.
>
> Dans la mesure où c'est un comportement indéfini, c'est au
> codeur de ne pas le faire. Si tous les codeurs étaient parfaits,
> et ne faisaient jamais d'erreur, c'est égal ce que fait strxxx
> dans ces cas-là. Autrement, il vaut mieux crasher le plus vite
> possible en cas d'erreur.
Je pense qu'ici il y a une tension entre la robustesse et la
correction.
Dans le cas d'un printf()/str*(), la question est "Est ce que ça porte
à conséquence que la chaine soit NULL ?"
Pas vraiment si on considère seulement la chaine de caractères et les
services rendus par ces fonctions (affichage, calcul, comparaison).
L'erreur existerait aussi si le programmeur s'était trompé de chaine à
comparer.
Dans ce cas, AMA la robustesse peut être un choix valide: si le codeur
doit avoir une chaine non NULL autre part, ce n'est pas en relation
avec les fonction strxxx(), et c'est donc de sa responsabilité de
vérifier ses contrats.
--
Michael
Marc Espie
Michael Doubez <michael...@free.fr> wrote:
>Dans le cas d'un printf()/str*(), la question est "Est ce que �a porte
>� cons�quence que la chaine soit NULL ?"
>Pas vraiment si on consid�re seulement la chaine de caract�res et les
>services rendus par ces fonctions (affichage, calcul, comparaison).
>comparer.
>Dans ce cas, AMA la robustesse peut �tre un choix valide: si le codeur
>doit avoir une chaine non NULL autre part, ce n'est pas en relation
>v�rifier ses contrats.
Non, en pratique ca fout une merde pas possible. Le bon comportement, ca
serait d'etre robuste *et* de diagnostiquer le probleme (en affichant
par exemple quelque chose sur stderr).
Dans ce cas extremement precis, ca fait des programmes qui segfaultent
des qu'on les compile et execute sur un Unix, et qui tournent sans broncher
cote Linux.
debug this fifo
>> caracteres valides, par exemple, ou encore cette idee saugrenue que les
>> pages de man, c'est du passe, et que info c'est mieux)...
> Sur ces points je suis largement d'accord avec toi. Surtout que c'est
> l'enfer de naviguer dans infos (d�sol�, je suis un Vimer).
>
un navigateur info a la mode lynx
https://alioth.debian.org/projects/pinfo/
ld
> Merci à tous pour vos réponses.
> Vu qu'il semble qu'il faut en passer par là, je vais déjà commencer par
> apprendre les Makefile.
Puisque c'est cette direction que vous avez choisi, jetez un oeil sur
la GNU Make Standard Library
Ca n'explique pas les fondements de make, mais plutot comment faire
des macros utiles.
a+, ld.
Gabriel Dos Reis
| On Nov 26, 8:49 am, Michael Doubez <michael.dou...@free.fr> wrote:
| > On 25 nov, 18:16, James Kanze <james.ka...@gmail.com> wrote:
| > [snip]
| > Il y a aussi les outils gnuwin32 (dont make) qui permettent
| > d'avoir les outils classics en win32 natif. Je les utilise
| > pour compléter mon install de MinGW avec sed, cat, wget ... et
| > même les expression [ - f ... ]. Le seul conflit que j'ai
| > trouvé avec Windows est avec echo et find.
|
| En effet.
|
| En général, les ports plus ou moins complets des outils Unix
| (CygWin, MinGW) s'integrent mal dans Windows, et posent des
Je n'ai pas de problème particulier avec MSYS/MinGW -- c'est une
plateforme de cross-compilation qui remplit largement son but. Il n'a
aucune prétention de fournir POSIX.
| problèmes quand on veut se servir aussi des programmes Windows.
| Tandis que les ports plus ou moins indépendants de chaque outil
| n'ont pas ce problème.
-- Gaby
Gabriel Dos Reis
[...]
| > Le principe d'Unix, c'est d'avoir des petits outils qui se comportent
| > bien entre eux.
| Je suis bien d'accord sur la philosophie Unix, mais en quoi le flag
| i de GNU sed contrevient à cette règle ?
ou celui de Perl.
-- Gaby
Gabriel Dos Reis
[...]
| Je pense que c'est comme en C quand tu utilises des macros en
| metalangage pour construire ton programme: tant que tu ne sors pas des
| chemins battus, ça se passe bien.
en général, on ne sort pas des chemins battus quand il s'agit de logiciel
non-expérimental :-)
| Ce qui veut dire que ça se passe bien en général :)
-- Gaby
Gabriel Dos Reis
[...]
| > Je voulais parler des autotools pour savoir ce que vous en pensiez
| >tous, et surtout si vous l'utilisiez. Mais vu ta réaction, j'ai peur que
| >ça ne tourne au Troll bien velu :'(
|
| Je pense enormement de mal des autotools. Typiquement, ces derniers temps
| ils permettent surtout de verifier que ca compile sur plusieurs variations
| de linux/i386... j'ai passe suffisamment de temps a corriger des tonnes de
| bugs sur ceux-ci pour ne plus du tout les aimer (entre autres, des cons
| qui utilisent sed -i dans un configure.ac...)
Je suis persuadé qu'ils apprécieront des patches pour les autres systèmes.
-- Gaby
Gabriel Dos Reis
| On Nov 26, 2:49 pm, Michael Doubez <michael.dou...@free.fr> wrote:
| > On 26 nov, 14:03, es...@lain.home (Marc Espie) wrote:
|
| > > In article <7e4eb714-457f-4f2e-beb0-07c3ae175...@g26g2000yqe.googlegroups.com>,
|
| [...]
| > > Parce que mv file file.old && sed <file.old >file c'est pas
| > > sorcier.
|
| > Et pourtant il y a une erreur pour avoir le même comportement
| > ;) mv file file.old && sed <file.old >file && rm file.old
|
| J'espère que ce n'est pas le comportement du -i. Sinon, c'est à
| éviter. Comme j'ai dire ailleurs, il ne faut pas détruire
| l'original si on rencontre une erreur lors de la transformation.
Dans ce cas, la commande 'rm file.old' n'est jamais exécutée. Non?
Gabriel Dos Reis
| In article <82b01131-bd18-46c4...@l13g2000yqb.googlegroups.com>,
| Michael Doubez <michael...@free.fr> wrote:
| >Dans le cas d'un printf()/str*(), la question est "Est ce que ça porte
| >à conséquence que la chaine soit NULL ?"
| >Pas vraiment si on considère seulement la chaine de caractères et les
| >services rendus par ces fonctions (affichage, calcul, comparaison).
| >L'erreur existerait aussi si le programmeur s'était trompé de chaine à
| >comparer.
| >Dans ce cas, AMA la robustesse peut être un choix valide: si le codeur
| >doit avoir une chaine non NULL autre part, ce n'est pas en relation
| >avec les fonction strxxx(), et c'est donc de sa responsabilité de
| >vérifier ses contrats.
|
| Non, en pratique ca fout une merde pas possible. Le bon comportement, ca
| serait d'etre robuste *et* de diagnostiquer le probleme (en affichant
| par exemple quelque chose sur stderr).
|
| Dans ce cas extremement precis, ca fait des programmes qui segfaultent
| des qu'on les compile et execute sur un Unix, et qui tournent sans broncher
| cote Linux.
Cela m'a l'air bien *nix-centrique, pour quelqu'un qui se plaint de la
dominance GNU/Linux.
-- Gaby
Marc Espie
C'est tout le framework qui est a jeter, a ce niveau... deja, distribue
du shell script auto-genere, beurk.
Tu veux un exemple ? il y a eu un probleme de securite dans libtool,
conduisant a une version *b d'une version existante.
Le gugusse qui a fait la release a eu l'idee geniale de tout verifier
sur son systeme, avec un nouvel automake. Resultat: 8000 lignes de diffs,
dans lesquelles chercher LE probleme de securite de deux lignes (pour
backporter sur une ancienne version)... pas tres surprenant qu'il y ait
deja eu plusieurs personnes qui foutent des troyens dans du auto*shit.
Pas grand monde n'a la patience pour s'assurer que les 8000 lignes de diffs
sont bien "du bruit" et pas des problemes.
Au passage, le code correspondant de libltdl est lui-meme a gerber. Je ne
serais pas surpris qu'il y ait d'autres failles dedans, vu l'immonde plat
de spaghettis et de tests divers et varies.
A mon avis, ca n'est pas du tout un hasard si kde, par exemple, s'est
finalement affranchi d'automake/autoconf/libtool. Entre autres, la structure
en Makefile recursifs augmentait terriblement les temps de compilation sur
toutes les plateformes disposant de plusieurs processeurs (make -j n'est
efficace QUE si on peut compiler plusieurs trucs dans le meme Makefile).
Mais bon, on est plus dans l'idee de faire une version qui marche de libtool
par exemple, meme si elle sera au depart reduite a OpenBSD, et ne suivant
pas les dogmes en vigueur (e.g., c'est du perl recent, et ca permet d'ores
et deja de compiler pas mal de trucs bien plus vite que le libtool gnu).
Et en plus, ca marche chez nous, sachant que reparer un shell-script de
8000 lignes qui prend l'eau de toutes parts, qui ne peut pas pas marcher
correctement pour autre chose que des lib elf linux, et qui n'a pas
reellement de notion de packager (on installe a l'endroit definitif...),
c'est du SM extreme...
TSalm
> On 24 nov, 22:21, TSalm <ts...@free.fr> wrote:
>> Merci ￜ tous pour vos rￜponses.
>> Vu qu'il semble qu'il faut en passer par lￜ, je vais dￜjￜ commencer par
>> ￜ
>> apprendre les Makefile.
>
> Puisque c'est cette direction que vous avez choisi, jetez un oeil sur
> la GNU Make Standard Library
>
> http://gmsl.sourceforge.net/
>
> Ca n'explique pas les fondements de make, mais plutot comment faire
> des macros utiles.
>
> a+, ld.
Bon, ce n'est pas encore trￜs utile ￜ mon (petit) niveau, mais je garde ￜa
de cￜtￜ.
Merci
Gabriel Dos Reis
| In article <87d433q...@gauss.cs.tamu.edu>,
| Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
| >es...@lain.home (Marc Espie) writes:
| >
| >[...]
| >
| >| > Je voulais parler des autotools pour savoir ce que vous en pensiez
| >| >tous, et surtout si vous l'utilisiez. Mais vu ta réaction, j'ai peur que
| >| >ça ne tourne au Troll bien velu :'(
| >|
| >| Je pense enormement de mal des autotools. Typiquement, ces derniers temps
| >| ils permettent surtout de verifier que ca compile sur plusieurs variations
| >| de linux/i386... j'ai passe suffisamment de temps a corriger des tonnes de
| >| bugs sur ceux-ci pour ne plus du tout les aimer (entre autres, des cons
| >| qui utilisent sed -i dans un configure.ac...)
| >
| >Je suis persuadé qu'ils apprécieront des patches pour les autres systèmes.
|
| C'est tout le framework qui est a jeter, a ce niveau... deja, distribue
| du shell script auto-genere, beurk.
Donc, ton probleme c'est pas qu'ils verifient que leur "truc" marche sur
des variations de linux/i386...
-- Gaby
Marc Espie
Ben, quand les problemes necessitent de tout refaire (ou presque) pour que
ca fonctionne ailleurs que sur des variations de linux/i386, c'est qu'il y
a un vrai souci.
James Kanze
> James Kanze <james.ka...@gmail.com> writes:
> > On Nov 26, 8:49 am, Michael Doubez <michael.dou...@free.fr> wrote:
> > > On 25 nov, 18:16, James Kanze <james.ka...@gmail.com> wrote:
> > > [snip]
> > > Il y a aussi les outils gnuwin32 (dont make) qui permettent
> > > d'avoir les outils classics en win32 natif. Je les utilise
> > > pour compléter mon install de MinGW avec sed, cat, wget ... et
> > > même les expression [ - f ... ]. Le seul conflit que j'ai
> > > trouvé avec Windows est avec echo et find.
> > En effet.
> > En général, les ports plus ou moins complets des outils Unix
> > (CygWin, MinGW) s'integrent mal dans Windows, et posent des
> Je n'ai pas de problème particulier avec MSYS/MinGW -- c'est
> une plateforme de cross-compilation qui remplit largement son
> but. Il n'a aucune prétention de fournir POSIX.
Ce n'est pas Posix que je démande ; je suis sous Windows, et non
sur une plateforme Unix. Et le problème et avec CygWin et avec
MinGW, c'est qu'ils essaient à cacher le fait. Les deux créent
leur propre image du système de fichiers, par exemple, avec
'/cygdrive/c/' sous CygWin et '/c/' sous MinGW. Ce qui veut dire
que sous CygWin, si tu entres le nom de fichier d'une façon que
l'achèvement des noms de fichiers marche, les autres programmes
ne le comprenent. MinGW, en revanche, le remappe (au moins dans
certains cas). Jusqu'à remplacer un '/' initial avec
"c:/msys/...", ce qui pose un problème pour les programmes
Windows, qui utilise '/' comme on utilise '-' sous Unix.
Si je voulais Unix (et quelque chose qui s'approche de Posix),
j'installerais Linux. Si je suis sous Windows, c'est que je veux
un certain nombre des fonctionalités de Windows. Si j'installe
CygWin ou MSys en plus, ce n'est pas que je veux un environement
Unix complet ; c'est que je veux quelques uns des fonctionalités
d'Unix dont je n'ai pas trouvé d'équivalent sous Windows -- des
choses comme awk, par exemple, où la version Unix de find (« find
| xargs egrep », c'est essentiel quand il faut se retrouver dans
une masse énorme de code existant, sans documentation). Voire
même la possibilité d'éditer la ligne de commande sans éloigner
mes doigts de la position de base. (Le shell Windows que je
connais ne permet l'édition qu'au moyen des touches de fleches.)
--
James Kanze
James Kanze
> James Kanze <james.ka...@gmail.com> writes:
> > > > In article <7e4eb714-457f-4f2e-beb0-07c3ae175...@g26g2000yqe.googlegroups.com>,
Non, mais le ficher « file » a quand même disparu. Je préfère de
loin la version :
sed file > unTemporaire && mv unTemporaire file
Mais évidemment, pour avoir la fonctionnalité de -i, il faudrait
plutôt :
for x
do sed $x > unTemporaire && mv unTemporaire $x
done
Et encore, le comportement n'est pas tout à fait identique en
cas d'erreur.
--
James Kanze