library's makefile

In article <49f1fadb$0$8275$426a74cc@news.free.fr>,
Paris Hilton <paris.hilton@open-bitches.com> wrote:

J'ai moi aussi utilisé make de façon récursive et je l'ai toujours
trouvé impec. Ce n'est pas le fait de l'utiliser de façon récursive qui
est mauvaise, je pense même qu'un seul makefile est une mauvaise idée,
un dossier doit pouvoir être compilé séparément du tout (on garde les
dépendances bien sûr), avoir un makefile global c'est comme empècher le
module de fonctionner tout seul et d'être réexploitable dans un autre
programme. Et le premier exemple qu'il cite dans son pdf est juste un
exemple de makefile incorrect où le mec n'a pas fait attention aux
dépendances (normalement le chef de projet met une claque).

Si, si, l'utilisation recursive est mauvaise. Ca rend totalement
impossible l'exploitation "correcte" en parallele. Demande aux gens
de kde ce qu'ils en pensent, et pourquoi ils ont arrete d'utiliser
automake et sont passes sur cmake a la place.

Paris Hilton wrote:

Alexandre Bacquart a écrit :

-ed- wrote:

On 21 avr, 01:42, alaxa27 <alax...@news.motzarella.org> wrote:

hello,
je suis en train de porter un librairie python ecrite en C sur
PSP(PlaystationSonyPortable) et je reste bloque a la creation du
makefile.

Pour démarrer :

http://mapage.noos.fr/emdel/make.htm

Mais ça ne concerne pas directement le langage C...

Sans vouloir lancer un débat (strictement hors-sujet ici) sur
l'utilisation de Make, je profite de cette occasion pour obtenir vos
avis éclairés sur l'excellent "Recursive Make Considered Harmful"
qu'on peut trouver ici :

http://miller.emu.id.au/pmiller/books/rmch/

Le document a 10 ans, certes, mais malgré son âge, tout ce que j'ai pu
dégotter à son sujet ne m'a pas vraiment satisfait. En effet, j'aurais
aimé trouver de véritables contre-arguments plutôt qu'uniquement des
approbations, voire des éloges. Utilisant make de manière sporadique
depuis bien longtemps, j'ai eu maintes fois l'occasion d'en supporter
les revers en ce qui concerne la récursivité (et qui n'a jamais eu à
lancer make plusieurs fois afin de compenser les trous générés par la
récursivité dans le diagramme des dépendances, peu motivé à l'idée
d'aller dépiauter le bouzin pour que cela n'arrive plus ?).

J'ai moi aussi utilisé make de façon récursive et je l'ai toujours
trouvé impec.

Fausse impression. La récursivité engendre des trous dans le diagramme
des dépendances. Le document de Miller démontre très bien cela, avec des
exemples simples et graphes à l'appui. Il gagne à être lu intégralement,
de manière posée et réfléchie, par les afficionados de la récursivité de
Make (et surtout par les chefs de projet).

J'ai toujours considéré la récursivité de Make comme une commodité
surexploitée (c'est justement ce qui m'a appâté dans le titre du
document lorsque je suis tombé dessus, il y a de cela quelques années,
et après lecture, je l'ai soigneusement archivé). Cet outil n'a pas été
pensé à la base pour être utilisé de la sorte. Le DAG se doit d'être
impeccable et il n'y a aucune raison (à part justement la récursivité
qui y est implémenté de manière trop rudimentaire) pour que Make déroge
à la règle, il en va de sa responsabilité. Miller aborde également les
raisons historiques de cette surexploitation (nécessaire peut-être, il
fût un temps, pour des raisons techniques qui ne sont plus valables
depuis bien longtemps).

Je ne voulais pas lancer de débat sur ce sujet ici : lire le document de
Miller. Son âge n'est peut-être pas motivant, il colle cependant encore
à la réalité et répond de manière souvent éloquente à la plupart des
protestations qui pourraient survenir des habitués de la chose. C'était
bien la raison pour laquelle j'ai timidement abordé le sujet ici, car il
y a des gens très compétents et je voulais leur opinion (et je ne doute
pas que tu en fasses partie, simplement, lis le document).

Ce n'est pas le fait de l'utiliser de façon récursive qui
est mauvaise, je pense même qu'un seul makefile est une mauvaise idée,

Il ne s'agit pas de cela. Miller aborde cette nuance dès le 3ème
paragraphe de son introduction, je cite :

"To avoid the symptoms, it is only necessary to avoid the separation; to
use a single make session to build the whole project, *which is not
quite the same as a single Makefile.*".

La suite, pour des raisons de clarté, considère le tout comme un seul
Makefile, mais il propose des techniques simples, basées sur la
directive "include" de make afin de palier à ce faux inconvénient.

Note qu'un compilateur C fonctionne selon le même principe avec
#include, mais il compte sur l'éditeur de liens pour corréler les
différents modules. Make n'a pas cette chance.

un dossier doit pouvoir être compilé séparément du tout (on garde les
dépendances bien sûr), avoir un makefile global c'est comme empècher le
module de fonctionner tout seul et d'être réexploitable dans un autre
programme.

Le sujet est "une seule *session* de Make", pas un seul Makefile. Miller
résout simplement le problème de modularité en passant des arguments à
Make (ce qui, franchement, est un inconvénient tout à fait mineur).

Et le premier exemple qu'il cite dans son pdf est juste un
exemple de makefile incorrect où le mec n'a pas fait attention aux
dépendances (normalement le chef de projet met une claque).

Le chef de projet aura raison de distribuer des claques si on ne
compense pas ces revers de la récursivité avec des techniques
particulières (bien que parfaitement connues) qui ne font que compliquer
la maintenance du bouzin. Ne pas exploiter la récursivité nécessite
d'autres techniques pour garder la modularité, mais au fond, elles sont
bien moins tirées par les cheveux.

Attention : je ne condamne pas la récursivité, mais son exploitation
démesurée et injustifiée. Rien n'empêche de combiner les différentes
techniques.


--
Alex

Marc Espie a écrit :

In article <49f1fadb$0$8275$426a74cc@news.free.fr>,
Paris Hilton <paris.hilton@open-bitches.com> wrote:

J'ai moi aussi utilisé make de façon récursive et je l'ai toujours
trouvé impec. Ce n'est pas le fait de l'utiliser de façon récursive qui
est mauvaise, je pense même qu'un seul makefile est une mauvaise idée,
un dossier doit pouvoir être compilé séparément du tout (on garde les
dépendances bien sûr), avoir un makefile global c'est comme empècher le
module de fonctionner tout seul et d'être réexploitable dans un autre
programme. Et le premier exemple qu'il cite dans son pdf est juste un
exemple de makefile incorrect où le mec n'a pas fait attention aux
dépendances (normalement le chef de projet met une claque).

Si, si, l'utilisation recursive est mauvaise. Ca rend totalement
impossible l'exploitation "correcte" en parallele. Demande aux gens
de kde ce qu'ils en pensent, et pourquoi ils ont arrete d'utiliser
automake et sont passes sur cmake a la place.

Dans ce cas là c'est que make a été pensé monothread et n'est pas thread
safe. Et ce n'est pas la récursivité qui est mises en doute mais la
façon qu'a make de la gérer.

In article <49f34fcb$0$23717$426a74cc@news.free.fr>,
Paris Hilton <paris.hilton@open-bitches.com> wrote:

Marc Espie a écrit :

In article <49f1fadb$0$8275$426a74cc@news.free.fr>,
Paris Hilton <paris.hilton@open-bitches.com> wrote:

J'ai moi aussi utilisé make de façon récursive et je l'ai toujours
trouvé impec. Ce n'est pas le fait de l'utiliser de façon récursive qui
est mauvaise, je pense même qu'un seul makefile est une mauvaise idée,
un dossier doit pouvoir être compilé séparément du tout (on garde les
dépendances bien sûr), avoir un makefile global c'est comme empècher le
module de fonctionner tout seul et d'être réexploitable dans un autre
programme. Et le premier exemple qu'il cite dans son pdf est juste un
exemple de makefile incorrect où le mec n'a pas fait attention aux
dépendances (normalement le chef de projet met une claque).

Si, si, l'utilisation recursive est mauvaise. Ca rend totalement
impossible l'exploitation "correcte" en parallele. Demande aux gens
de kde ce qu'ils en pensent, et pourquoi ils ont arrete d'utiliser
automake et sont passes sur cmake a la place.

Dans ce cas là c'est que make a été pensé monothread et n'est pas thread
safe. Et ce n'est pas la récursivité qui est mises en doute mais la
façon qu'a make de la gérer.

N'importe quoi.

Qu'est-ce que tu appelles la recursivite dans make, alors ?

Moi, c'est ce dont parle l'auteur du papier en question, que j'ai lu un
certain nombre de fois, qui explique expressement qu'avoir make qui s'appelle
lui-meme dans des sous-repertoires, c'est une mauvaise idee... entre
autres parce que ca conduit a reevaluer plusieurs fois un arbre partiel
de dependances, et aussi parce que make n'a aucune facon de connaitre
l'arbre total...

Il faut juste un seul outil global qui sache ce qu'il faut construire, et
dans quel ordre, ca permet d'avoir l'arbre complet de dependances.
C'est ce que fait cmake, qui s'en sert pour fabriquer des makefile un peu
plus complets que ce qu'un etre humain peut faire.

Ca n'a absolument aucun rapport avec le cote monothread/multithread.
D'ailleurs, les make paralleles sont rarement multithread, ils sont
plutot multi-process en general... ;-)

Si tu fais un arbre de dependances complet, tu as des cycles, assez
souvent. Et make fonctionne quand meme tant que tu ne lui demandes pas
d'evaluer une cible qui passe par un cycle. Lorsque tu mets plusieurs
makefile et des make distincts (c'est ce que veut dire "recursive make
considered harmful", hein), tu te retrouves avec une approximation de ce
graphe... si tu veux qu'elle soit complete (couvre toutes les dependances),
tu as bien plus de chance de te retrouver dans un cycle (parce que chaque
make n'a qu'une vision partielle de l'ensemble et doit bien interroger
ses voisins pour savoir), ou alors il faut laisser tomber des
dependances... ce qui fait que parfois, tu ne vas pas reconstruire
tout ce qu'il faudrait. La seule "solution" c'est de rajouter des commandes
specifiques pour briser les cycles quand il faut (des fragments de
shell-scripts qui en savent "un peu plus" sur ce qu'il faut construire qu'un
bete cd dir && make all)

Bref, c'est vite le bordel. C'est pas efficace. Et ca va tres mal paralleliser
de toutes facons...

Le 24/04/2009 17:46, Paris Hilton écrivit :

http://miller.emu.id.au/pmiller/books/rmch/

[...] le premier exemple qu'il cite dans son pdf est juste un
exemple de makefile incorrect où le mec n'a pas fait attention aux
dépendances (normalement le chef de projet met une claque).

Pour information, le premier concerne un projet avec main.c, parse.h et
parse.c, et le Makefile proposé est:
OBJ = main.o parse.o
prog: $(OBJ)
$(CC) -o $@ $(OBJ)
main.o: main.c parse.h
$(CC) -c main.c
parse.o: parse.c parse.h
$(CC) -c parse.c

Et j'ai du mal à voir l'erreur dans les dépendances. Mlle la cheffe de
projet pourrait-elle nous expliquer où se trouve l'erreur, plutôt que de
mettre des claques ?


Antoine

In article <gt25sh$f9s$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:

Le 24/04/2009 17:46, Paris Hilton écrivit :

http://miller.emu.id.au/pmiller/books/rmch/

[...] le premier exemple qu'il cite dans son pdf est juste un
exemple de makefile incorrect où le mec n'a pas fait attention aux
dépendances (normalement le chef de projet met une claque).

Pour information, le premier concerne un projet avec main.c, parse.h et
parse.c, et le Makefile proposé est:
OBJ = main.o parse.o
prog: $(OBJ)
$(CC) -o $@ $(OBJ)
main.o: main.c parse.h
$(CC) -c main.c
parse.o: parse.c parse.h
$(CC) -c parse.c

Et j'ai du mal à voir l'erreur dans les dépendances. Mlle la cheffe de
projet pourrait-elle nous expliquer où se trouve l'erreur, plutôt que de
mettre des claques ?

Independamment d'autres choses, c'est moche comme Makefile. Ca s'abrege en

OBJ = main.o parse.o
prog: $(OBJ)
$(CC) $(CFLAGS) -o $@ $(OBJ)
main.o parse.o: parse.h

et le reste est automatique dans tout make qui se respecte. ;-)

Antoine Leca a écrit :

Le 24/04/2009 17:46, Paris Hilton écrivit :

http://miller.emu.id.au/pmiller/books/rmch/

[...] le premier exemple qu'il cite dans son pdf est juste un
exemple de makefile incorrect où le mec n'a pas fait attention aux
dépendances (normalement le chef de projet met une claque).

Pour information, le premier concerne un projet avec main.c, parse.h et
parse.c, et le Makefile proposé est:
OBJ = main.o parse.o
prog: $(OBJ)
$(CC) -o $@ $(OBJ)
main.o: main.c parse.h
$(CC) -c main.c
parse.o: parse.c parse.h
$(CC) -c parse.c

Et j'ai du mal à voir l'erreur dans les dépendances. Mlle la cheffe de
projet pourrait-elle nous expliquer où se trouve l'erreur, plutôt que de
mettre des claques ?

Le mec il va piocher au milieu d'un fichier le .h dont il a besoin
CLAQUE, il devrait juste dire je suis dépendant de l'autre dossier c'est
tout. Il ne sait rien de ce dossier il doit le considérer comme un tout.
Même si au premier abord il pense n'avoir besoin que du .h

Antoine

Paris Hilton a écrit :

Antoine Leca a écrit :

Le 24/04/2009 17:46, Paris Hilton écrivit :

http://miller.emu.id.au/pmiller/books/rmch/

[...] le premier exemple qu'il cite dans son pdf est juste un
exemple de makefile incorrect où le mec n'a pas fait attention aux
dépendances (normalement le chef de projet met une claque).

Pour information, le premier concerne un projet avec main.c, parse.h et
parse.c, et le Makefile proposé est:
OBJ = main.o parse.o
prog: $(OBJ)
$(CC) -o $@ $(OBJ)
main.o: main.c parse.h
$(CC) -c main.c
parse.o: parse.c parse.h
$(CC) -c parse.c

Et j'ai du mal à voir l'erreur dans les dépendances. Mlle la cheffe de
projet pourrait-elle nous expliquer où se trouve l'erreur, plutôt que de
mettre des claques ?

Le mec il va piocher au milieu d'un fichier le .h dont il a besoin
CLAQUE, il devrait juste dire je suis dépendant de l'autre dossier c'est
tout. Il ne sait rien de ce dossier il doit le considérer comme un tout.
Même si au premier abord il pense n'avoir besoin que du .h

note il peut aussi appeler le make parse.h pour s'assurer d'avoir la
bonne version.

Antoine

In article <49f4c2ec$0$32394$426a74cc@news.free.fr>,
Paris Hilton <paris.hilton@open-bitches.com> wrote:

Antoine Leca a écrit :

Le 24/04/2009 17:46, Paris Hilton écrivit :

http://miller.emu.id.au/pmiller/books/rmch/

[...] le premier exemple qu'il cite dans son pdf est juste un
exemple de makefile incorrect où le mec n'a pas fait attention aux
dépendances (normalement le chef de projet met une claque).

Pour information, le premier concerne un projet avec main.c, parse.h et
parse.c, et le Makefile proposé est:
OBJ = main.o parse.o
prog: $(OBJ)
$(CC) -o $@ $(OBJ)
main.o: main.c parse.h
$(CC) -c main.c
parse.o: parse.c parse.h
$(CC) -c parse.c

Et j'ai du mal à voir l'erreur dans les dépendances. Mlle la cheffe de
projet pourrait-elle nous expliquer où se trouve l'erreur, plutôt que de
mettre des claques ?

Le mec il va piocher au milieu d'un fichier le .h dont il a besoin
CLAQUE, il devrait juste dire je suis dépendant de l'autre dossier c'est
tout. Il ne sait rien de ce dossier il doit le considérer comme un tout.
Même si au premier abord il pense n'avoir besoin que du .h

C'est comme ca que tu termines rapidement avec des cycles dans ton graphe
de dependances, ou des compilations d'une heure la ou 30 secondes
suffiraient...

In article <49f4c2ec$0$32394$426a74cc@news.free.fr>,
Paris Hilton <paris.hilton@open-bitches.com> wrote:

Le mec il va piocher au milieu d'un fichier le .h dont il a besoin
CLAQUE, il devrait juste dire je suis dépendant de l'autre dossier c'est
tout. Il ne sait rien de ce dossier il doit le considérer comme un tout.
Même si au premier abord il pense n'avoir besoin que du .h

Oh, et puis j'oubliais. Pourquoi je m'emmerde a repondre a un troll qui
n'y connait rien et qui n'est meme pas foutu d'utiliser son vrai nom sur
usenet ?