Outil Make simple

On Nov 25, 10:19 am, es...@lain.home (Marc Espie) wrote:

In article
<576df9ab-6cb0-4cf2-821c-c738ba67c...@f16g2000yqm.googlegroups.com>,
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

On 25 nov, 18:16, James Kanze <james.ka...@gmail.com> wrote:
[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

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
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

In article <7e4eb714-457f-4f2e-beb0-07c3ae175149@g26g2000yqe.googlegroups.com>,
Michael Doubez <michael.doubez@free.fr> wrote:

On 25 nov, 18:16, James Kanze <james.ka...@gmail.com> wrote:
[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.

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)...

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).

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

On 26 nov, 14:03, es...@lain.home (Marc Espie) wrote:

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]

>> 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 pl us
>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 mieu x
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

On 26 nov, 15:48, Mickaël Wolff <mickael.wo...@laposte.net> wrote:

Marc Espie a écrit :
   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 qu e
ç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 v os 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

In article <4b0e952a$0$30385$426a74cc@news.free.fr>,
Mickaël Wolff <mickael.wolff@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.

In article <bf7c82a0-01c5-455e-a814-d752c8387862@m16g2000yqc.googlegroups.com>,
Michael Doubez <michael.doubez@free.fr> wrote:

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.

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)...

On Nov 26, 1:03 pm, es...@lain.home (Marc Espie) wrote:

In article
<7e4eb714-457f-4f2e-beb0-07c3ae175...@g26g2000yqe.googlegroups.com>,
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