On 26 nov, 14:03, (Marc Espie) wrote:
> In article ps.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
> 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.
On 26 nov, 14:03, es...@lain.home (Marc Espie) wrote:
> In article <7e4eb714-457f-4f2e-beb0-07c3ae175...@g26g2000yqe.googlegrou ps.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
> 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.
On 26 nov, 14:03, (Marc Espie) wrote:
> In article ps.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
> 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.
On Nov 26, 2:49 pm, Michael Doubez wrote:
> On 26 nov, 14:03, (Marc Espie) wrote:
> > In article oups.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.
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.googlegr oups.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.
On Nov 26, 2:49 pm, Michael Doubez wrote:
> On 26 nov, 14:03, (Marc Espie) wrote:
> > In article oups.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.
On 26 nov, 19:53, James Kanze wrote:
> On Nov 26, 2:49 pm, Michael Doubez wrote:
> > On 26 nov, 14:03, (Marc Espie) wrote:
> > > In article
> > > ,
> [...]
> > > 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.
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.
> [...]
> > > 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.
On 26 nov, 19:53, James Kanze wrote:
> On Nov 26, 2:49 pm, Michael Doubez wrote:
> > On 26 nov, 14:03, (Marc Espie) wrote:
> > > In article
> > > ,
> [...]
> > > 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.
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.)
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.)
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.)
On Nov 27, 8:43 am, Michael Doubez wrote:
> On 26 nov, 19:53, James Kanze wrote:
> > On Nov 26, 2:49 pm, Michael Doubez wrote:
> > > On 26 nov, 14:03, (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.
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.
On Nov 27, 8:43 am, Michael Doubez wrote:
> On 26 nov, 19:53, James Kanze wrote:
> > On Nov 26, 2:49 pm, Michael Doubez wrote:
> > > On 26 nov, 14:03, (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.
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.
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.
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.
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).
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).
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).
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.
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.
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.