Car il faut compiler chaque dépendance statiquement, et chaque dépendance de chaque dépendance, etc... C'est énormément de travail sur des grosses libs genre Qt !
On est bien d'accords, malheureusement.
heureusement, on a inventé les makefile pour lister les dépendances, les compiler une seule fois,
Tu connais beaucoup de gros projets dont le makefile n'est pas généré? Linux, peut-être, mais j'imagine qu'il ne link pas dynamique, de fait :)
Au-dela de ça, maintenir un makefile est assez difficile pour que les devs d'i3, notamment, soient passés aux autotools, puis (à en lire les commits) à meson.
Écrire son makefile est une plaie, vraiment. D'ailleurs, makefile pour quelle variante? Celle de GNU? De BSD? Un autre? Variante de quelle version?
Je préfère de loin écrire moi-même un ninja, c'est du même niveau, mais au moins je sais qu'il n'existe qu'une seule version, le fichier peut décrire pour quelle version il est censé fonctionner, et, d'ailleurs, ninja, contrairement à make (à ma connaissance), peut deviner de quels headers un .c ou .cpp à besoin, et ça, ça change la vie.
Il est aussi possible de gérer facilement quand une règle à plusieurs entrées et plusieurs sorties (utilisation de compilateurs de compilateurs (non, pas une faute de frappe)) ce que j'ai été incapable de faire proprement avec GNU make quand je me suis mis à coco-cppp.
Et puis, tout ça ne change pas le problème. Les outils en C et C++ sont, à ma connaissance, mauvais pour gérer l'ordonnancement des dépendances, et les link pètent tout le temps, avec des erreurs tout sauf compréhensibles (comment ça le symbole est pas présent? Le fichier contiens le symbole, est bien listé... ah putain il faut le décaler d'un cran dans la ligne de commande!!!).
Un jour, peut-être, je testerais mk de plan9... il paraît qu'il est intéressant, mais j'avoue que pour l'instant j'aime bien ninja (même si je devrais pas écrire mes ninja à la main...).
[^] # Re: delicat à chiffrer
Posté par freem . En réponse au message Différence entre une application AppImage et une application installée. Évalué à 2.
On est bien d'accords, malheureusement.
Tu connais beaucoup de gros projets dont le makefile n'est pas généré? Linux, peut-être, mais j'imagine qu'il ne link pas dynamique, de fait :)
Au-dela de ça, maintenir un makefile est assez difficile pour que les devs d'i3, notamment, soient passés aux autotools, puis (à en lire les commits) à meson.
Écrire son makefile est une plaie, vraiment. D'ailleurs, makefile pour quelle variante? Celle de GNU? De BSD? Un autre? Variante de quelle version?
Je préfère de loin écrire moi-même un ninja, c'est du même niveau, mais au moins je sais qu'il n'existe qu'une seule version, le fichier peut décrire pour quelle version il est censé fonctionner, et, d'ailleurs, ninja, contrairement à make (à ma connaissance), peut deviner de quels headers un .c ou .cpp à besoin, et ça, ça change la vie.
Il est aussi possible de gérer facilement quand une règle à plusieurs entrées et plusieurs sorties (utilisation de compilateurs de compilateurs (non, pas une faute de frappe)) ce que j'ai été incapable de faire proprement avec GNU make quand je me suis mis à coco-cppp.
Et puis, tout ça ne change pas le problème. Les outils en C et C++ sont, à ma connaissance, mauvais pour gérer l'ordonnancement des dépendances, et les link pètent tout le temps, avec des erreurs tout sauf compréhensibles (comment ça le symbole est pas présent? Le fichier contiens le symbole, est bien listé... ah putain il faut le décaler d'un cran dans la ligne de commande!!!).
Un jour, peut-être, je testerais mk de plan9... il paraît qu'il est intéressant, mais j'avoue que pour l'instant j'aime bien ninja (même si je devrais pas écrire mes ninja à la main...).