xilun@xilun:~/bla$ make 2>&1 | grep error | wc
1145 9106 104917
xilun@xilun:~/bla$ make 2>&1 | wc
1668 11494 136955
1668 lignes dont 1145 d'erreurs (en majorité dans /usr/include) pondues par GCC qui décide que cela vaut tout de même la peine de continuer. Évidemment l'erreur (de syntaxe) est de ma faute à la base, mais est-ce pour autant la peine d'overflooder mon terminal avec de la merde dans laquelle seul ce qui est TOUT EN HAUT m'intéresse.
xilun@xilun:~$ gcc --version
gcc (Debian 4.3.1-9) 4.3.1
# Oui
Posté par ham . Évalué à 10.
que continuer permet de voir les autres erreurs qui peuvent quand meme exister, qui ne dependent pas forcement de celle la (dure de determiner que l'erreur affecte tout le code et pas une partie).
moi ca me soulerais encore plus de relancer 15 fois gcc pour 15 petite erreurs (; par-ci, par-la) parceque gcc s'arrette a la premiere.
j'utilise tj emacs pour compiler, sinon tee est ton amis.
[^] # Re: Oui
Posté par Lucas . Évalué à 5.
Je m'étonne que personne n'ai donné -Wfatal-errors:
-Wfatal-errors
This option causes the compiler to abort compilation on the first
error occurred rather than trying to keep going and printing
further error messages.
[^] # Re: Oui
Posté par Guillaume Knispel . Évalué à 4.
Toute personne ayant déjà oublié un ";" à la fin d'un prototype dans un header a été confronté au délire de GCC souhaitant "rattraper" les erreurs de syntaxe (toutes...) pour être "gentil", et à donc le réflexe intuitif de regarder l'incompréhensible première erreur uniquement pour récupérer le numéro de ligne (en sachant par avance qu'on aura 99% de chance de fixer le truc en y mettant ";" à la fin).
Bref la correction du problème qui a entraîné la rédaction de ce journal m'a pris moins d'une minute (parce que confronté régulièrement à ce genre d'idioties, j'ai pris la précaution depuis lontemps de régler le tampon de mes terminaux à un nombre de lignes délirant ce qui m'a permis de remonter sans même relancer le build). Ce que je voulais dénoncer, c'est le manque de pragmatisme, de concessions. Y-a-t'il _vraiment_ une personne sur terre qui a déjà trouvé 1145 erreurs de compilation utiles au delà de disons, prenons _très_ large, ... les 100 premières ? -> et hop un peu de pragmatisme et une valeur par défaut saine (quitte à rajouter une option pour régler précisément le comportement pour éviter que les gens ralent devant une telle limitation scandaleuse, même si jamais personne n'utilisera en pratique la-dite option)
Pour info mon programme fait ~6000 lignes selon sloccount. Je n'ose imaginer la quantité de faux positifs potentiellement provoqués par une erreur dans un header de certains projets de 300k lignes.
[^] # Re: Oui
Posté par windu.2b . Évalué à 1.
Cela fait partie, selon moi, du B-A BA de tout bon IDE (avec la coloration syntaxique et la complétion du code)...
Bref, selon moi, ce genre d'erreurs détectables à la compilation ne devrait du coup jamais arriver lorsqu'on lance la compilation de tout le bouzin !
Ou alors, je suis trop habitué à coder en Java avec Eclipse...
[^] # Re: Oui
Posté par Guillaume Knispel . Évalué à 2.
De plus je ne me suis pas habitué à utiliser un IDE sous Linux lors de mes débuts sous cet OS et j'ai du mal à changer cette habitude - avant 2000 y'avait pas grand chose qui arrivait ne serait-ce qu'à la hauteur d'un bon vieux Turbo C sous DOS ergonomiquement parlant, et les vim et emacs étaient trop exotique de mon point de vue => je vais probablement faire dresser les cheveux sur la tête de quelqu'uns (et rappeler des souvenirs à d'autres) mais je codais sous mcedit à l'époque (sur un 486). Aujourd'hui X-Window me permet d'avoir autant de terminaux que je veux dans lesquels je mélange des builds et d'autres choses, donc je n'accroche pas plus sur les IDE - d'autant que je bosse typiquement sur un assez grand nombre de paquets, mais plutôt de manière très ponctuelle sur chaque, et que des grands coups de rgrep dans un shell donne de meilleurs résultats dans ce cas là.
# Simple
Posté par Kouenny . Évalué à 9.
make 2>&1 | head
# jour & nuit
Posté par tfeserver tfe (site web personnel) . Évalué à 10.
Comme quoi la nuit, il vaut mieux dormir. La fatigue nous fait parfois pondre des journaux pas très utils.
# Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Quelques questions
Posté par Frédéric-Emmanuel Picca . Évalué à 4.
[^] # Re: Quelques questions
Posté par Troy McClure (site web personnel) . Évalué à 6.
[^] # Re: Quelques questions
Posté par briaeros007 . Évalué à 10.
/me siflotte
[^] # Re: Quelques questions
Posté par RB . Évalué à 10.
LANG=C++ make
---> []
[^] # Re: Quelques questions
Posté par TImaniac (site web personnel) . Évalué à 2.
# man gcc
Posté par vincent LECOQ (site web personnel) . Évalué à 4.
[^] # Re: man gcc
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
[^] # Re: man gcc
Posté par andeus . Évalué à 3.
# J'aime bien ce comportement moi !
Posté par gUI (Mastodon) . Évalué à 5.
Ensuite à toi, selon ce que tu veux, de manipuler ce comportement (via des '|', ou des options, il y en a plusieurs de citées dans les autres commentaires).
Si tu n'avais que 3 ou 4 erreurs, tu dirais : "pourquoi il me montre que la première, alors que si il me les montrait toutes, je pourrais les corriger d'un coup ?"
Comportement complexe = plus de bugs, c'est inéluctable. C'est justement ce que je reproche 9 fois sur 10 aux produits Microsoft : "mais de quoi ils se mèlent !!!"
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: J'aime bien ce comportement moi !
Posté par FX Pasquier . Évalué à 7.
Ce que je déteste le plus, c'est de lancer une compile *sensé* être longue, aller prendre un café, et me rendre compte en revenant qu'il s'est arrêté à la deuxième ligne de code pour une excuse aussi peu valable que "Internal Compiler Error" ... pfffft visual roulez qu'ils disaient.
[^] # Re: J'aime bien ce comportement moi !
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
[^] # Re: J'aime bien ce comportement moi !
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Euh, si c'est ça l'argument, ça prêche en faveur de l'arret à la première erreur, non ? La récupération d'erreur dans les compilateurs, c'est une question pas évident à résoudre correctement (et GCC est particulièrement mauvais sur ce point), la solution triviale, c'est de s'arrêter de suite.
# IDE
Posté par IsNotGood . Évalué à 8.
# Sur l'introspection...
Posté par cosmocat . Évalué à 8.
Il arrive de nombreuses fois dans l'utilisation de l'informatique qu'on trouve des outils bien trop complexes et qu'on se dit bien que ça devrait être beaucoup plus simple mais bien souvent les choix sont réfléchis et c'est parce qu'on ne perçoit pas l'ensemble des tenants et aboutissant qu'on produit une mauvaise réflexion.
Quoiqu'il en soit ta méthode pour obtenir de l'aide est somme toute bien trouvée.....
[^] # Re: Sur l'introspection...
Posté par Thomas Douillard . Évalué à 4.
[^] # Re: Sur l'introspection...
Posté par briaeros007 . Évalué à 2.
# ta faute
Posté par rewind (Mastodon) . Évalué à 6.
[^] # Re: ta faute
Posté par Thomas Douillard . Évalué à 3.
# Euh...
Posté par 2PetitsVerres . Évalué à 3.
J'ai plutôt l'impression que c'est ton Makefile qui dit de continuer...
* sauf s'il n'y a qu'une commande dans le Makefile
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Euh...
Posté par Guillaume Knispel . Évalué à 2.
# Petite note
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Les gestion des erreurs de compilation, c'est une tâche *vraiment* lourde dans l'écriture d'un compilo (ou même d'un interpréteur).
Quand on voit la taille de GCC, on se dit qu'il est rudement bon quand même !
Cela étant, oui, c'est un peu fatiguant de décortiquer l'erreur (vraiment une erreur de syntaxe ? un bug dans GCC ? un typo dans mon code ?)
Mais on s'y fait vite, car chaque classe d'erreurs génère en fait un type d'erreur identique... De plus, les IDEs, et éditeurs (y compris VIM) te mettent le curseur sur la première erreur trouvée (et les suivantes si tu cliquouilles ou tape la bonne commande (:cnext, :cc par exemple avec vim))
[^] # Re: Petite note
Posté par briaeros007 . Évalué à 2.
Les gestion des erreurs de compilation, c'est une tâche *vraiment* lourde dans l'écriture d'un compilo (ou même d'un interpréteur).
Le coup de "c'est dur" ou "tu sais pas le faire" n'est pas une "excuse" valable. Ca peut etre une explication, mais pas une excuse.
Oui une tache peut être très lourde et difficile, est ce pour autant qu'il faut faire n'importe quoi (attention je ne parle pas de gcc mais en général) ?
Bien sur que non.
[^] # Re: Petite note
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Et si l'"excuse" ne te satisfait pas, alors j'y peux rien.
Ils n'ont pas à s'excuser auprès de toi (ou de quiconque), mais *tu* dois te contenter de la justification ou utiliser un autre programme (ou mieux ! patcher GCC)
Mais trimballe toi un AST avec informations de types, positions des tokens, et essaye de remonter à la transformation de code ou à l'evaluation partielle qui a généré l'erreur, et on en reparlera...
Fais le juste pour un interprète d'expressions arithmétiques...
Tu verras que se contenter d'un comportement basique ne signifie en rien "faire n'importe quoi".
Te dire "on va juste garde la ligne du token", ca peut vouloir dire immédiatement des *milliers* de répercussions sur ton code... (bon, tu dois pouvoir embarquer ça dans une monade ou toute autre bonne abstraction fonctionnelle, mais comme les gens veulent toujours coder dans des langages pas forcément adaptés aux tâches qu'ils doivent résoudre...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.