[F] [mOved] Mon langage est mieux que le tien - Page 65

Godzil (./1918) :
Heu en terme de syntaxe peut etre oui, mais cmake n'est qu'un generateur de makefile.

Non. Ca génère un truc qui s'appelle ensuite avec make, mais ca ne génère pas de vrai Makefile.

Sinon autotools est ce qui se fait de pire.. mais bon

Si l'outil make le mange et ne se plein pas, chez mois c'est que c'est un makefile.

Sinon un fichier C genere par flex/yacc & co n'est pas un fichier C?

Sur qu'un fichier Makefile qui ressemble à all: @cmake --target=all install: @cmake --target=install est un Makefile parfaitement valide

Non cmake n'est utilisé que pour verifier que les cmakfile n'ont pas été changé et faire certains calculs que make est incapable de faire, sinon, les makefiles soint bordelique comparé a des makefile fait mains, mais c'est bel et bien make qui gere les dépendances et appellent les executable a lancer.

Godzil (./1924) :
sinon, les makefiles soint bordelique comparé a des makefile fait mains

CQFD.

Mais justement, on s'en fout complètement, non ?

oui et en plus tes autotools préféré font des makefiles bien pire..

Folco (./1926) :
Mais justement, on s'en fout complètement, non ?

Non, car une fois sur quatre, ca ne compile pas, et il faut débugguer, et c'est alors une merde infinie.

1 fois sur 4 ?
CMake a marche 1000 fois sur 1000 chez mois mais bon, et si un probleme il y a ca n'a jamais été dans le makefile

Mais est-ce que PpHd ne lit pas les Makefile pour trouver ses bugs de CMake, de la même manière que je lis les fichiers assembleur pour trouver mes bugs en C ?
Auquel cas, je peux comprendre

Si tu fais ca c'est qeu tu t'es trompé de cremerie

Edit: si tu prefere c'est plutot "tu prends le probleme du mauvais coté".
Si GCC ou CMake te genere du code invalide, le premier truc a regarder c'est TON code pas celui qui est générer. Et si vraiment c'est un bug de l'outil, tu commence par chercher un usecase simple, et si et seulement si tu as un usecase simple tu peux regarder ce qui se passe.

Mais a vrai dire je prefere debugger du makefile generé par cmake que pas automake/autoconf/configure & co

Folco (./1930) :
Mais est-ce que PpHd ne lit pas les Makefile pour trouver ses bugs de CMake, de la même manière que je lis les fichiers assembleur pour trouver mes bugs en C ?

Pour trouver les bugs de CMake qui ne prend pas le bon compilateur, les bonnes options de compilation, n'installe pas où il faut, fait le lien avec de mauvaises libraries, etc. etc.

Alors c'est que le bug est entre la chaise et le clavier, tout simplement.

PpHd (./1917) :
Et je déteste cmake. Je préfère larguement autotools (mais vous connaissez déjà mon opinion la dessus).

Bizarre. Moi, c'est exactement le contraire. Les autotools sont un bidouillage totalement imbitable:

• Il faut connaître au moins 5 langages différents (avec des syntaxes différentes, imbriquées l'une dans l'autre) pour les utiliser sérieusement (autoconf, m4, shell, automake, make).
• Le mode d'utilisation conseillé est de ne pas livrer juste les vraies sources, mais aussi des fichiers prégénérés. L'idée est de ne nécessiter rien de plus qu'un "simple shell", mais sous le système d'exploitation le plus utilisé, un "simple shell" est beaucoup plus compliqué à installer qu'un simple exécutable comme CMake. Et les fichiers prégénérés font que si on veut corriger un bogue, ou adapter le code pour trouver une bibliothèque aux exigences d'une distribution particulière, il faut patcher tous les logiciels qui utilisent les autotools. Les fichiers prégénérés sont d'ailleurs totalement illisibles, parce qu'ils ont choisi de contourner les erreurs dans tous les shells Bourne-like possibles et imaginables au lieu de présupposer un shell un minimum standard.
• Il y a régulièrement des changements incompatibles dans le langage (une raison de plus pour laquelle ils conseillent de toujours livrer les fichiers prégénérés avec les projets ).
• La bidouille m4 + shell rame à fond par rapport à un exécutable natif comme CMake.
• Autoconf s'obstine par défaut à tester plein de propriétés que de toute façon toute source moderne présuppose depuis des années (parce qu'elles font partie par exemple du standard C de 1989/1990!). Tous ces tests pour des trucs évidents comme HAVE_STDIO_H sont ensuite complètement ignorés par pratiquement toutes les sources, ce n'est que du temps perdu pour rien.

Folco (./1919) :
J'ai l'impression que autotools est de moins en moins répandu, c'est réel ou pas ?

Normal, vu la bouse obsolète que c'est, et vu qu'il y a des alternatives plus modernes comme CMake.

PpHd (./1925) :

Godzil (./1924) :
sinon, les makefiles soint bordelique comparé a des makefile fait mains

CQFD.

Maintenant, compare un configure généré par autoconf à un shell script écrit par une forme de vie intelligente. Ou même les makefiles d'automake à des makefiles faits à la main, d'ailleurs.

Concernant l'argument des fichiers générés, ça me semble logique de livrer les fichiers produits par les autotools avec les binaires de l'exécutable, ou bien les fichiers sources avec les fichiers sources du projet, un mix des deux serait un choix très curieux ? (je me fais l'avocat du diable ceci dit, je n'aime pas non plus les autotools)

[edit] générer => livrer, sinon la phrase n'a aucun sens ^^

Kevin Kofler (./1934) :
Le mode d'utilisation conseillé est de ne pas livrer juste les vraies sources, mais aussi des fichiers prégénérés. L'idée est de ne nécessiter rien de plus qu'un "simple shell",

Et c'est très bien, non ?

mais sous le système d'exploitation le plus utilisé, un "simple shell" est beaucoup plus compliqué à installer qu'un simple exécutable comme CMake.

Non. C'est exactement équivalent. Ils existent plein de shell pour Windows: msys2, mobaxterm, cygwin, bash4win10. Je dirai même que c'est plus simple : mobaxterm n'a même pas besoin d'être installé pour fonctionner. Et l'installeur de CMake pour Windows demande à desinstaller à la main la version précédente avant d'installer la nouvelle version.

Et les fichiers prégénérés font que si on veut corriger un bogue, ou adapter le code pour trouver une bibliothèque aux exigences d'une distribution particulière, il faut patcher tous
les logiciels qui utilisent les autotools.

Soit je n'ai absolument pas compris ce que tu racontes, soit tu ne sais vraiment pas utiliser un script configure.

Les fichiers prégénérés sont d'ailleurs totalement illisibles, parce qu'ils ont choisi de contourner les erreurs dans tous les shells Bourne-like possibles et imaginables au lieu de présupposer un shell un minimum standard.

C'est tout à fait lisible. Moche à lire, mais lisible.

Il y a régulièrement des changements incompatibles dans le langage (une raison de plus pour laquelle ils conseillent de toujours livrer les fichiers prégénérés avec les projets ).

Les fichiers autotools proprement écrit ne sont que rarement impacté. Seuls les fichiers autotools qui tapent dans les détails d'implémentation sont impactés.
Et franchement, c'est plus propre qu'avant !

La bidouille m4 + shell rame à fond par rapport à un exécutable natif comme CMake.

C'est vrai. Au moins, elle marche elle.

Autoconf s'obstine par défaut à tester plein de propriétés que de toute façon toute source moderne présuppose depuis des années (parce qu'elles font partie par exemple du standard C de 1989/1990!). Tous ces tests pour des trucs évidents comme HAVE_STDIO_H sont ensuite complètement ignorés par pratiquement toutes les sources, ce n'est que du temps perdu pour rien.

Non. Seulement si tu lui demandes de le faire.

Maintenant, compare un configure généré par autoconf à un shell script écrit par une forme de vie intelligente. Ou même les makefiles d'automake à des makefiles faits à la main, d'ailleurs.

Et bien voilà :

• joli: Makefile manuel >> Makefile autotols >> Makefile cmake
• bug free: Makefile autotols > Makefile manuel ~ Makefile cmake

Pour compléter, je suis d'accord sur plusieurs défauts:

• Ca rame à mort sous Windows, mais c'est la faute du noyau Windows de ne pas avoir implanter d'appel "fork"
• Ca ne s’intègre pas aux IDE
• Des paquets abusent des autotools (genre un configure alors que tu es dans l'étape du make ou des tests inutiles ou des tests ré-implémentés mais bugués)

oui ca sux de lancer un make et de se retaper des tonnes de configure. gcc/binutils font ca d'ailleurs.

PpHd (./1936) :
Et l'installeur de CMake pour Windows demande à desinstaller à la main la version précédente avant d'installer la nouvelle version.

mauvais installateur, changer installateur

PpHd (./1936) :
Ca rame à mort sous Windows, mais c'est la faute du noyau Windows de ne pas avoir implanter d'appel "fork"

Chapeau, t'es presque autant de mauvaise foi que Kevin quand tu t'y mets

PpHd est un troll, et la le niveau est vraiment tres tres tres bas, j'ai connu bien mieux de sa part..

Zeph (./1935) :
Concernant l'argument des fichiers générés, ça me semble logique de générer les fichiers produits par les autotools avec les binaires de l'exécutable, ou bien les fichiers sources avec les fichiers sources du projet, un mix des deux serait un choix très curieux ? (je me fais l'avocat du diable ceci dit, je n'aime pas non plus les autotools)

Avec le binaire, on n'a plus du tout besoin des fichiers générés par les autotools, parce qu'ils ne sont utilisés que pour la compilation. Pour les autotools, il y a vraiment 4 étapes: les vraies sources (configure.ac, Makefile.am), les "sources" "à distribuer" (avec les fichiers prégénérés: configure, Makefile.in), les "sources" "configurées" (config.h, Makefile) et enfin les binaires (l'exécutable du logiciel compilé). La plupart des projets distribuent effectivement les "sources à distribuer" avec fichiers prégénérés, l'utilisateur ne fait plus que ./configure (→ "sources configurées") et make (→ binaires).

PpHd (./1936) :

Kevin Kofler (./1934) :
Le mode d'utilisation conseillé est de ne pas livrer juste les vraies sources, mais aussi des fichiers prégénérés. L'idée est de ne nécessiter rien de plus qu'un "simple shell",

Et c'est très bien, non ?

Non, parce que ça implique plein de choix de conception très discutables:

• compatibilité avec tous les shells Bourne-like possibles et imaginables, aussi bogués qu'ils soient (le nombre de fois que je lis "workaround for a bug in the [OS propriétaire exotique et obsolète] sh", où "[OS propriétaire exotique et obsolète]" est très variable, c'est rarement 2 fois le même, est à vomir ),
• livraison de fichiers prégénérés dans les "sources". Un fichier prégénéré n'est par définition pas une source, il n'a rien à faire dans les sources,
• utilisation du langage shell, particulièrement inefficace niveau performance (langage interprété, processus externes),

le tout seulement pour éviter à l'utilisateur d'installer un simple exécutable.

Et les fichiers prégénérés font que si on veut corriger un bogue, ou adapter le code pour trouver une bibliothèque aux exigences d'une distribution particulière, il faut patcher tous
les logiciels qui utilisent les autotools.

Soit je n'ai absolument pas compris ce que tu racontes, soit tu ne sais vraiment pas utiliser un script configure.

Ça doit être la première solution.

Par exemple, sous Fedora, pour permettre la coexistence de kdelibs3-devel et kdelibs4-devel, kdelibs 4 a été modifié pour installer les symlinks non versionnés (comme libkdecore.so) dans un répertoire dédié (/usr/lib/kde4/devel). Avec CMake, c'était un seul fichier contenu dans le paquetage de kdelibs 4 à modifier, et ça marche pour tous les logiciels qui utilisent CMake. Mais pour les projets utilisant les autotools, il a fallu bidouiller chaque projet séparément.

Un autre exemple est la (non-)gestion de /usr/lib64 dans certaines versions de libtool, avec la fâcheuse habitude de mettre /usr/lib64 dans le RPATH (ce qui empêche de remplacer les bibliothèques système par d'autres à travers ld.so.conf.d, par exemple la libGL de NVidia, ou une libfreetype compilée avec le subpixel antialiasing, donc c'est interdit dans les paquetages Fedora). Des centaines de paquetages Fedora utilisent des patches ou workarounds pour ce problème.

Les fichiers prégénérés sont d'ailleurs totalement illisibles, parce qu'ils ont choisi de contourner les erreurs dans tous les shells Bourne-like possibles et imaginables au lieu de présupposer un shell un minimum standard.

C'est tout à fait lisible. Moche à lire, mais lisible.

Tu dois trouver les entrées de l'IOCCC lisibles, aussi, alors.

Il y a régulièrement des changements incompatibles dans le langage (une raison de plus pour laquelle ils conseillent de toujours livrer les fichiers prégénérés avec les projets ).

Les fichiers autotools proprement écrit ne sont que rarement impacté. Seuls les fichiers autotools qui tapent dans les détails d'implémentation sont impactés.Et franchement, c'est plus propre qu'avant !

Il y a eu plein de changements à plein d'endroits, certains ont impacté pratiquement tous les projets.

La bidouille m4 + shell rame à fond par rapport à un exécutable natif comme CMake.

C'est vrai. Au moins, elle marche elle.

LOL, le troll! CMake marche très bien.

Autoconf s'obstine par défaut à tester plein de propriétés que de toute façon toute source moderne présuppose depuis des années (parce qu'elles font partie par exemple du standard C de 1989/1990!). Tous ces tests pour des trucs évidents comme HAVE_STDIO_H sont ensuite complètement ignorés par pratiquement toutes les sources, ce n'est que du temps perdu pour rien.

Non. Seulement si tu lui demandes de le faire.

Plein de projets ont ces tests inutiles en pratique (cf. par exemple les libti* de Romain Liévin). Probablement parce que presque personne ne comprend vraiment les autotools, tout le monde fait du copier-coller.

Kevin Kofler (./1942) :
le tout seulement pour éviter à l'utilisateur d'installer un simple exécutable.

Ce qui est globalement faut, combien de fois j'ai eu a executer un automake ou autoconf juste parceque le configure ne marche pas poru X ou Y raison car incompatible avec X ou Y car trop ancien, car bidule ou autre.

Non pour pouvoir utiliser lse autotools il *FAUT* avoir la suite d'executable plus le milliers* de fichier qui va avec juste pour pouvoir compiler un(e) *** de logiciel/lib


*nombre a la louche marseillaise

Zerosquare (./1939) :
Chapeau, t'es presque autant de mauvaise foi que Kevin quand tu t'y mets

A moitié.Je ne sais pas si ca a été réglé avec Win10.

Kevin Kofler (./1942) :
Non, parce que ça implique plein de choix de conception très discutables:

Ah !

compatibilité avec tous les shells Bourne-like possibles et imaginables, aussi bogués qu'ils soient (le nombre de fois que je lis "workaround for a bug in the [OS propriétaire exotique et obsolète] sh", où "[OS propriétaire exotique et obsolète]" est très variable, c'est rarement 2 fois le même, est à vomir ),

Sûr. Il y en a beaucoup:

$ grep -i work configure|grep -i around| wc -l
7

livraison de fichiers prégénérés dans les "sources". Un fichier prégénéré n'est par définition pas une source, il n'a rien à faire dans les sources,

Les arguments ontologiques ne comptent pas !

utilisation du langage shell, particulièrement inefficace niveau performance (langage interprété, processus externes),

C'est sûr que python est tellement plus rapide !

le tout seulement pour éviter à l'utilisateur d'installer un simple exécutable.

$ cmake
bash: cmake: command not found

Par exemple, sous Fedora, pour permettre la coexistence de kdelibs3-devel et kdelibs4-devel, kdelibs 4 a été modifié pour installer les symlinks non versionnés (comme libkdecore.so) dans un répertoire dédié (/usr/lib/kde4/devel). Avec CMake, c'était un seul fichier contenu dans le paquetage de kdelibs 4 à modifier, et ça marche pour tous les logiciels qui utilisent CMake. Mais pour les projets utilisant les autotools, il a fallu bidouiller chaque projet séparément.

Option --with-kde4-lib= manquante ?

Un autre exemple est la (non-)gestion de /usr/lib64 dans certaines versions de libtool, avec la fâcheuse habitude de mettre /usr/lib64 dans le RPATH (ce qui empêche de remplacer les bibliothèques système par d'autres à travers ld.so.conf.d, par exemple la libGL de NVidia, ou une libfreetype compilée avec le subpixel antialiasing, donc c'est interdit dans les paquetages Fedora). Des centaines de paquetages Fedora utilisent des patches ou workarounds pour ce problème.

autoreconf -i pour mettre à jour la version de libtool ?

Tu dois trouver les entrées de l'IOCCC lisibles, aussi, alors.

C'est ce que j'ai l'impression de lire en lisant les Makefile généré par cmake pour trouver où est l'erreur qui m'emêche de compiler.

Il y a eu plein de changements à plein d'endroits, certains ont impacté pratiquement tous les projets.

Je n'ai pas de tels souvenirs. De toute façon, c'est le développeur qui maitrise sa migration de version. Il peut migrer quand il veut, cela n'a pas d'impact sur l'utilisateur.

LOL, le troll! CMake marche très bien.

Sauf lorsqu'il récupère un mauvais compilateur,
Sauf lorsqu'il récupère une mauvaise librarie, ..
(ok, ca n'arrive pas souvent, mais lorsque ca arrive, c'est la merde)

Plein de projets ont ces tests inutiles en pratique (cf. par exemple les libti* de Romain Liévin). Probablement parce que presque personne ne comprend vraiment les autotools, tout le monde fait du copier-coller.

Suivre un bon tutorial me semble être un bon départ : https://autotools.io/index.html

Tu sais si cmake ne va pas chercher le bon ya un moyen SUPER simple

ccmake path

tu passe en mode avancé et tu modifie les champs correspondant aux lib qu'il a mal trouvé

et paf pasteque.

Bref, un troll gros et velu qui ne sais pas utiliser l'outil.

Ah, enfin un débat technique avec PpHd, ça me manquait! Ça change du nucléaire et des voitures. Le seul truc bizarre, c'est que c'est moi qui défends la solution qui nécessite un logiciel à installer centralement (CMake) et PpHd qui défend celle qui se contente de ce qui est déjà installé sur le système (les scripts prégénérés des autotools).

PpHd (./1944) :
Sûr. Il y en a beaucoup:

$ grep -i work configure|grep -i around| wc -l
7

Il y a aussi des commentaires formulés différemment, par exemple:
# WARNING: Do not start the trap code with a newline, due to a FreeBSD 4.0 bug.

C'est sûr que python est tellement plus rapide !

CMake est en C++, pas en Python.

$ cmake
bash: cmake: command not found

sma()
                Done

Option --with-kde4-lib= manquante ?

Déjà, comme il n'y a pas de macro standard pour trouver les kdelibs avec les autotools (normal, les autotools sont dépréciés dans KDE depuis des années, il faut utiliser CMake), les projets ont tous leurs propres bidouilles, et la plupart ne prend aucune option. Et ensuite, passer une telle option à chaque configure nécessiterait quand-même de modifier tous les specfiles; avec CMake, c'est un seul (le paquetage qui contient FindKDE4Internal.cmake, installé dans le système).

Un autre exemple est la (non-)gestion de /usr/lib64 dans certaines versions de libtool, avec la fâcheuse habitude de mettre /usr/lib64 dans le RPATH (ce qui empêche de remplacer les bibliothèques système par d'autres à travers ld.so.conf.d, par exemple la libGL de NVidia, ou une libfreetype compilée avec le subpixel antialiasing, donc c'est interdit dans les paquetages Fedora). Des centaines de paquetages Fedora utilisent des patches ou workarounds pour ce problème.

autoreconf -i pour mettre à jour la version de libtool ?

Certains paquetages utilisent effectivement ça (c'est la solution la plus propre), mais ça a d'autres inconvénients (par exemple, le risque de se taper une incompatibilité entre versions), et donc certains packagers préfèrent utiliser des workarounds beaucoup plus sales dans leurs paquetages. Et puis, à quoi bon livrer les fichiers prégénérés si on doit de toute façon les regénérer?

Tu dois trouver les entrées de l'IOCCC lisibles, aussi, alors.

C'est ce que j'ai l'impression de lire en lisant les Makefile généré par cmake pour trouver où est l'erreur qui m'emêche de compiler.

Le bordel infâme que génère automake n'est pas mieux.

De toute façon, c'est le développeur qui maitrise sa migration de version. Il peut migrer quand il veut, cela n'a pas d'impact sur l'utilisateur.

Sauf s'il doit regénérer les fichiers, soit pour corriger un bogue des générateurs (ou des fichiers copiés tels quels) (comme le cas de libtool ci-dessus), soit parce qu'il veut exercer son droit de modification sur le logiciel libre.

LOL, le troll! CMake marche très bien.

Sauf lorsqu'il récupère un mauvais compilateur,
Sauf lorsqu'il récupère une mauvaise librarie, ..
(ok, ca n'arrive pas souvent, mais lorsque ca arrive, c'est la merde)

Tu peux redéfinir pratiquement tous les chemins détectés par Find*.cmake si ceux qu'il te trouve ne te conviennent pas.

On fork cette discussion vers un "[trolloscope] Autotools vs the world" ?

Ils peuvent si ils y tiennent, ie si l'un est persuadé de parvenir à convaincre l'autre
Après, ce topic est justement dédié à ce genre de conversations à batons rompus

Oui mais si je veux troller sur autre chose ici