Le but de cette dépêche est de recenser quelques outils utiles pour les développeurs (pas uniquement C et C++) et de donner accès à des ressources intéressantes pour leur prise en main.
Tout d’abord comment définit‐on un « outil utile » ? Ce sont des logiciels (libres, c’est mieux) qu’il n’est pas obligatoire d’utiliser mais qui permettent de gagner en productivité (ou de moins se prendre la tête avec un bogue). Ces outils sont utilisables indépendamment, mais utilisés ensemble peuvent former un tout qui donne les fonctionnalités d’un environnement de développement intégré.
Il est fort probable que pour certains cette dépêche vienne enfoncer des portes ouvertes. Mais pensez aux nouveaux pour qui elle sera, peut‐être, profitable.
Sommaire
Makefile
Voir aussi CMake plus loin.
Make est sûrement l’outil le plus connu et donc le plus utilisé, mais savez‐vous vraiment tirer parti de toute sa puissance ?
Make est un utilitaire qui permet d’automatiser la compilation. Pour fonctionner, il a besoin d’un fichier Makefile
qui contiendra essentiellement des blocs ayant cette apparence :
cible : dépendances
commandes à exécuter
Il est possible de déclarer des variables, pour faciliter l’écriture et la maintenance de fichiers Makefile
. Certaines implémentations de Make proposent aussi des extensions, comme des variables internes qui accélèrent l’écriture de tels fichiers, comme :
-
$@
, le nom de la cible ; -
$<
, le nom de la première dépendance ; -
$^
, la liste des dépendances.
Comme cette dépêche n’a pour but que la présentation des outils, voici un bon tutoriel d’introduction à Makefile pour débuter.
CTags
CTags est un outil très utile quand votre projet commence à avoir pas mal de fichiers. En effet, il permet de retrouver la déclaration ou la définition d’une variable ou d’une fonction. Il existe de nombreux greffons pour les éditeurs les plus connus (emacs, vim, kate…).
Valgrind
Valgrind est en fait un ensemble d’outils. Celui qui nous intéresse dans le cadre de cette dépêche est MemCheck. Il permet d’exécuter un programme et d’obtenir une synthèse de l’état de son tas. Ainsi, il est facile de détecter et corriger les fuites mémoire avec un tel outil. Je vous recommande cette introduction à memcheck.
Time
Time est une simple commande Unix qui permet de mesurer la durée d’exécution d’un programme. De prime abord, ça ne paye pas de mine, mais cela peut se révéler assez utile.
Doxygen
Doxygen permet de générer de la documentation dans plusieurs formats (comme HTML ou ) pour plusieurs langages de programmation (C, C++, Java, VHDL…). Pour ce faire, il faudra ajouter des commentaires avec une syntaxe un peu particulière à certains endroits de votre code, par exemple, pour documenter une fonction vous devrez ajouter le commentaire avant son prototype. Voici le lien d’une initiation à Doxygen.
Clang/LLVM
Clang est un compilateur C, C++ et Objective-C qui s’appuie sur LLVM. Il tente d’être compatible avec GCC (il utilise les mêmes options) et avec MSVC. Il utilise une licence libre non copyleft.
Il s’approche peu à peu de GCC au niveau performance du code généré, mais il a surtout une interface utilisateur bien meilleure (même s’il a poussé GCC à de gros efforts à ce niveau) :
- il affiche erreurs et diagnostic en couleurs de façon très claire ;
- il propose des corrections pour certaines erreurs (fautes de frappe) ;
- il est plus rapide pour compiler que GCC.
Autre gros point fort, sa conception est modulaire et il expose une énorme partie de ses fonctionnalités dans des bibliothèques (par exemple, il est très simple de parcourir l’AST), ce qui permet à beaucoup d’outils d’exister autour de lui :
- clang-format pour l’indentation du code, non pas ligne à ligne, mais globalement. Il peut, par exemple, transformer un appel de fonction avec des paramètres sur des lignes isolées en un appel mono‐ligne si le résultat n’est pas trop long. Debian fournit un paquet ;
- clang-tidy propose des détections et corrections de bogues courants. C’est une collection de vérifications (checks) et il est assez aisé d’en ajouter de nouvelles. Debian propose un paquet ;
- clang static analyzer est, comme son nom l’indique, un analyseur statique (comme cppcheck). Il tente de trouver des bogues en lisant le code. Il est assez utile malgré des faux positifs assez présents ;
- clang et LLVM ont introduit des sanitizers qui permettent d’instrumenter le code pour trouver des bogues à l’exécution (comme Valgrind). Les plus connus sont ASAN et TSAN (address sanitizer et thread sanitizer), mais d’autres se sont greffés au cours du temps. Ils ont été portés sous GCC. Ils sont vraiment très puissants et pratiques pour détecter des bogues lors des tests. En particulier, sous GCC undefined behaviour sanitizer.
GDB (GNU Debugger)
GDB est le débogueur standard du projet GNU. Il est portable sur de nombreux systèmes type Unix et fonctionne pour plusieurs langages de programmation, comme le C, le C++ et le Fortran.
Il est aussi possible d’utiliser rr pour rejouer ce qui a été mémorisé.
CMake
CMake est un moteur de production (build automaton) de plus haut niveau que Make ou SCons. Il est à placer au même niveau qu'Autotools puisqu'il permet de générer des Makefiles.
Il utilise un DSL (Domain Specific Language ou langage dédié) pour ses fichiers de configuration pour décrire les constructions (builds) et génère des fichiers Makefile
ou équivalent pour make, ninja, voire carrément pour des EDI, tels que Visual Studio, XCode et d’autres.
Un exemple vaut mieux qu’un long discours :
cmake_minimum_required (VERSION 2.8.11)
project (HELLO)
add_executable (helloDemo demo.cxx demo_b.cxx)
target_include_directories (Hello includes)
Va compiler un exécutable helloDemo
à partir des fichiers demo.cxx
et demo_b.cxx
, en cherchant les fichiers d’en‐têtes déclarés par les #include
dans le répertoire includes
.
Quant à l’utilisation :
$ # create build tree
$ cmake /path/to/project
$ # build
$ make
ou avec ninja :
$ # create build tree
$ cmake -GNinja /path/to/project
$ # build
$ ninja
Cscope
Cscope est un navigateur de code source C, créé à l’époque du PDP-11 par les Bell Labs. Il a été libéré en 2000 par SCO sous une licence BSD. Il utilise une interface texte en mode plein écran.
# Merci à tous les contributeurs !
Posté par Eiffel . Évalué à 3.
Je remercie tous les contributeurs et notamment ceux qui ont décidé de sortir cette dépêche.
Tout le mérite leur revient car à part initier la dépêche je n'ai pas fait grand chose…
# Compilateurs
Posté par David Marec . Évalué à 8. Dernière modification le 03 mars 2017 à 10:41.
Pourquoi ne mentionner que CLang ?
Pour les plus curieux, d'autres sont disponibles:
J'ajouterais:
nm
,ltrace
,ktrace
,kdump
et cie.ld
), commeldd
.patch
,diff
.[^] # Re: Compilateurs
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Il y en a plein d'autres qui sont libres, par exemple:
* Open Watcom
* SDCC (pour l'embarqué, PIC, z80, …)
[^] # Re: Compilateurs
Posté par lmg HS (site web personnel) . Évalué à 7. Dernière modification le 06 mars 2017 à 12:17.
Peut-être parce qu'au delà que c'est un compilateur, clang permet développer quantité d'outils qui vont pouvoir nous assister dans nos tâches quotidiennes, même si la compilation est réalisée avec un compilateur dédié pour ne pas dire exotique parfois.
Les sanitizers ont été cité. Depuis je n'utilise pratiquement plus valgrind. J'ai plus d'informations et plus vite pour les corruptions du tas. J'ai aussi tous les comportements non définis détectés (à l'exécution). Il y a des furieux qui en train d'écrire un efficiency-sanitizer.
Côté analyse-statique de code, il y a des trucs classiques via clang-analyse et clang-tidy. Mais aussi un détecteur statique d'inter-blocages et de courses aux données (moyennant annotations). Quantité d'autres outils d'analyse de code source: OCLint, CppDepend… J'ai même croisé une outil de vérification des règles MISRA C et C++—qui donc à l'a différence d'outils tels que Understand a partage son noyau d'analyse des sources, avec un compilateur C++. Ce n'est pas anodin.
J'ai aussi croisé des outils d'indexation de code ou de refactoring basés sur clang. Plus qu'un IDE a repris ses solutions internes pour travailler sur des codes C et C++ pour des solutions basées sur clang.
Dans les trucs peu conventionnels, on peut aussi citer Cling, une refonte de Clint (si j'ai bien suivi), qui permet d'interpréter du C++.
Encore plus tordu, il y templight, un A C++ Template Metaprogram Debugger and Profiler comme ils disent.
Bref. Clang a initié une révolution dans l'outillage disponible pour travailler en C++. Et il a enrichit le catalogue d'outils pour le C. Et de fait je comprends qu'il soit cité en outillage, chose qui va bien au delà de "un petit compilateur dédié ou restreint à des cas spécifiques". Ce qui me rappelle un machin qui ne sert à rien: un compilateur C écrit (ou plutôt traduit) dans le langage de script de Vim https://github.com/rhysd/8cc.vim. Dans la série, en plus utile, c'est à clang/LLVM que l'on doit les compilateurs C/C++ -> javascripts.
[^] # Re: Compilateurs
Posté par lmg HS (site web personnel) . Évalué à 0.
(Quelle horreurs ces fautes, et je ne peux plus éditer mon message :-( )
# git / svn?
Posté par Anonyme . Évalué à 2.
Les logiciels de gestion de version, est-ce bien nécessaire?
[^] # Re: git / svn?
Posté par David Marec . Évalué à 1.
Cela dépend du point de vue.
Du point de vue du développeur, stricto sensu, c'est un outil de gestion de projet.
Il n'est pas utile pour produire, déverminer ou tester (quoique) son code.
Il sert à le publier.
D'un autre coté, c'est utile pour le maintenir.
[^] # Re: git / svn?
Posté par DerekSagan . Évalué à 6.
Tu veux dire que ça ne sert qu'après le premier commit ?
L'association pour la liberté sexuelle des mouches envisage de porter plainte.
[^] # Re: git / svn?
Posté par BAKfr . Évalué à 7.
C'est vrai que ce n'est pas utile pour produire du code ou le tester.
En revanche, si tu penses que c'est inutile pour déverminer, c'est que tu ne connais pas
git bisect
.[^] # Re: git / svn?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10.
La fonction annuler/refaire d'un éditeur de texte est-elle utile pour produire du code? Je me sers beaucoup de git comme une extension (ou généralisation) de cette fonctionnalité (persistance sur le disque, gestion de plusieurs fichiers, etc).
Pour moi c'est un outil indispensable pour produire du code.
[^] # Re: git / svn?
Posté par Anonyme . Évalué à 2.
Je dirais que c'est indispensable pour les projets qui ont plus d'un développeur.
[^] # Re: git / svn?
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 10.
C’est utile même pour une seule personne, et pas seulement pour du code (par ex. pour des fichiers de configuration).
[^] # Re: git / svn?
Posté par barmic . Évalué à 4. Dernière modification le 03 mars 2017 à 16:25.
T'a jamais utilisé bisect toi (ni git/hg grep d'ailleurs).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: git / svn?
Posté par DerekSagan . Évalué à 2.
ni même git log
# Un bon compagnon à GDB
Posté par Adrien BUSTANY (site web personnel) . Évalué à 10.
RR ( http://rr-project.org/ ) est un excellent compagnon à GDB: on enregistre une fois une exécution d'un programme, et on a débugge cette exécution autant de fois qu'on veut, avec la possibilité de "stepper" en avant ou en arrière (ie. "remonter dans le temps"). Le tout avec l'interface normale de GDB.
Et en parlant de GDB, la vidéo "Give me 15 minutes & I'll change your view of GDB" ( https://www.youtube.com/watch?v=PorfLSr3DDI ) expose des fonctionnalités sympathiques et peu connues de GDB (notamment son interface "graphique" en ncurses) de manière didactique et concise.
[^] # Re: Un bon compagnon à GDB
Posté par Adrien BUSTANY (site web personnel) . Évalué à 5.
Argh, rr était déjà mentionné dans la dépêche, que j'ai lue apparemment trop vite… Il est cependant incorrect de dire que rr "rejoue ce que GDB a mémorisé". rr va enregistrer tous les inputs non déterministes lors de l'exécution d'un programme (appels systèmes de lecture clavier/réseau/horloge/…), et les simuler lors de la rééxécution. GDB trace l'exécution le code, et RR lui fournit le "contenu" des appels système (de manière simplifiée). Autrement dit, GDB n'a rien mémorisé lui même.
[^] # Re: Un bon compagnon à GDB
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
Corrigé, merci.
# Petite correction
Posté par Jona . Évalué à -1.
Dans le paragraphe sur Clang :
licence sans copyleft -> "licence sans copyright" ou "licence copyleft"
[^] # Re: Petite correction
Posté par louiz’ (site web personnel) . Évalué à 3.
Ben… non. C’est une license libre, sans copyleft.
C’est ni une license « sans copyright », ni une license « copyleft » (« copyleft » ne veut pas dire « sans copyright », au passage)
[^] # Re: Petite correction
Posté par rewind (Mastodon) . Évalué à 6.
Non, la formule «licence sans copyleft» est peut-être maladroite mais correcte. La licence de LLVM est une licence libre non-copyleft (un dérivé de BSD). Le terme «licence sans copyright» ne veut rien dire puisqu'une licence de logiciel (libre ou pas) s'appuie sur le copyright (ou le droit d'auteur).
[^] # Re: Petite correction
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# valgrind --tool=callgrind
Posté par rewind (Mastodon) . Évalué à 8. Dernière modification le 03 mars 2017 à 11:37.
Avec Valgrind, j'utilise beaucoup Callgrind qui fonctionne un peu comme gprof mais sans devoir instrumenter le code, donc sans changer les options de compilation. Avec des outils comme KCacheGrind qui permettent de visualiser les résultats graphiquement, on a un outil super puissant pour trouver les problèmes de performances (quand il y en a).
[^] # Re: valgrind --tool=callgrind
Posté par Shuba . Évalué à 4.
En effet le couple callgrind + kcachegrind est assez sympa, mais ça reste très long de faire tourner le code sous callgrind.
Souvent je trouve qu'un bon usage de perf avec flamegraph est un bon compromis.
[^] # Re: valgrind --tool=callgrind
Posté par TNorth . Évalué à 5.
Et en tout neuf, il y a heaptrack:
https://www.kdab.com/heaptrack-v1-0-0-release/
qui prétend être plus rapide que Valgrind et est accompagné d'une interface graphique sympathique.
# D'autres outils
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
Moins connus mais pas forcément moins utiles:
Et pour aller avec CMake, il me paraît intéressant de mentionner CTest (un moteur pour faire des tests unitaires) et CPack (pour générer facilement des pauqets deb, rpm, et même des installeurs pour Windows). Tous les deux sont utilisables avec ou sans CMake, mais sont assez bien intégrés dans ce dernier.
[^] # Re: D'autres outils
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Plus pour tester que pour développer :
# Autour du projet
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
plantuml Pour la conception.
kanboard Pour gérer son projet en mode à Gilles.
taskjuggler Pour gérer ses ressources et son planning sans Gilles.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Autour du projet
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Et le très complet ProjeQtOr, mais là, on est plus vraiment dans les outils pour les développeurs…
[^] # Re: Autour du projet
Posté par damiend . Évalué à 3.
Phabricator a l'air très complet.
[^] # Re: Autour du projet
Posté par DerekSagan . Évalué à 0. Dernière modification le 05 mars 2017 à 12:16.
[supprimé par l'auteur, j'avais dit une connerie]
# CMake n'est pas de plus haut niveau qu'Autotools
Posté par YuGiOhJCJ (site web personnel) . Évalué à 5.
Je pense qu'il y a une erreur sur cette phrase : "CMake est un moteur de production (build automaton) de plus haut niveau que le triplet formé par Make, Scons et Autotools.".
Je suis d'accord que CMake est à un niveau au-dessus de Make puisqu'il permet de générer des Makefiles.
Par contre, CMake est au même niveau qu'Autotools (autoconf/automake/…).
En effet, avec Autotools on peut générer des Makefiles également tout comme CMake.
Une correction pour ta phrase serait :
"CMake est un moteur de production (build automaton) de plus haut niveau que Make ou SCons. Il est à placer au même niveau qu'Autotools puisqu'il permet de générer des Makefiles.".
[^] # Re: CMake n'est pas de plus haut niveau qu'Autotools
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# lint pour l'analyse statique de code
Posté par podoc . Évalué à 1.
Déjà essayé, et c'est vrai qu'il retourne des sources potentiels de bug
[^] # Re: lint pour l'analyse statique de code
Posté par gpe . Évalué à 1. Dernière modification le 06 mars 2017 à 15:58.
En analyse statique de code il y aussi Sonarqube. Le moteur est libre mais tous les jeux de règles ne le sont pas.
# cppcheck / jenkins / cppunit
Posté par hurdmann . Évalué à 2.
Il faut pas oublier la qualité de code, avec cppcheck / jenkins et cppunit ( et il y en a d'autres !)
[^] # Re: cppcheck / jenkins / cppunit
Posté par Philippe F (site web personnel) . Évalué à 2.
googletest est un cran au dessus de cppunit. Enfin une lib de test unitaire bien conçue !
[^] # Re: cppcheck / jenkins / cppunit
Posté par lmg HS (site web personnel) . Évalué à 3.
cppunit n'a jamais été très bon. Déjà il y a 20 ans, cxxtest(.sf.Net) avait compris le principe de Don't Repeat Yourself (DRY pour les intimes). Ces dernières années ont été dominées par boost.test et google.test. Et nous avons catch en challenger pas mal du tout.
A noter qu'ils s'intègrent tous très facilement dans CTest et son (C)Dashboard associé.
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Défaut de présentation d'un lien hypertexte
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
Corrigé, merci.
# Clang sous Windows ?
Posté par Tarnyko (site web personnel) . Évalué à 4.
Que donne Clang en termes de performances et compatibilité sous Windows ?
J'aimerais bien le supporter à côté de GCC/MinGW et MSVC pour mes projets cross-platform ; il y a quelques années quand j'avais regardé, c'était très bogué, limite expérimental.
On trouve aujourd'hui des instructions pour le compiler soi-même dessus, mais peu d'indications sur son état fonctionnel. Des retours ?
# Un bon compagnon : Qt, qmake & QtCreator
Posté par AncalagonTotof . Évalué à 10.
Hello,
Je ne peux plus me passer de Qt, même pour des projets qui n'utilisent pas cette librairie. Par exemple, un projet qui tourne sur un microcontrôleur de type STM32.
QtCreator
J'utilise QtCreator comme IDE, pour l'édition de code uniquement. Ce que j’apprécie particulièrement, c'est qu'il est fait par des dév, pour des dév : aucun icône, aucune barre d'outils ne vient polluer l'écran. Le maximum de surface est dédié au code.
À l'aide de scripts, je crée un projet Qt (un fichier .pro). Les directives a utiliser en premier lieu sont :
Le script suivant,
makeQtPro.sh
chez moi, est incomplet (il ne gère pas INCLUDEPATH et DEPENDPATH), mais c'est un début :Je l'utilise en ce moment pour l'évaluation de TouchGFX et Embedded Wizard, deux outils concurrents pour faire des interfaces graphique "à la smartphone" sur microcontrôleurs.
Je l'appelle de la façon suivante :
pour un projet simple :
makeQtPro.sh > nomDuProjet.pro
pour une librairie :
makeQtPro.sh > nomDuProjet.pri
Ensuite, il suffit de créer un .pro qui fait des include :
include(nomDuProjet.pri)
Il n'y a plus qu'à demander à QtCreator de charger le .pro.
Quelques tips :
il est possible d'ajouter des directives du genre :
SOURCES += mon/chemin/vers/du/code/source/*.c
Ça peut être pratique, mais cette fois, la mise à jour ne se fait que si le .pro est modifier et sauvegardé.
je laisse en exercice l'ajout des directives INCLUDEPATH et DEPENDPATH. Le jeu en vaut la chandelle : grâce à elles, vous aurez les hyperliens dans le code : un
<CTRL>+clic
sur une fonctions, par exemple, vous amènera à sa déclaration ou sa définition. Courage : un peu de dirname, de basename, de sort et uniq …il est fréquent que certaines portions de code dépendent de "define". Facile :
DEFINES += STM32F429_439xx
pour activer les portions de code relatives au microcontroleur STM32F429 ou 439. Le
<CTRL>+clic
fonctionnera pour ces portions de code aussi après ça.qmake
Comme je le disais plus haut, je cible fréquemment du microcontrôleur. Je "cross-compile" donc. Et on peut aller plus loin, dans ce sens, avec
qmake
.Si votre .pro (et vos .pri) sont bien construit, si ils comportent les directives nécessaires pour pointer le cross-compilateur, comme CC, CFLAGS, etc, vous pouvez demander à
qmake
de vous générer unMakefile
automatiquement. Sacré gain de temps !Plus loin, plus haut, plus fort ?
Et encore plus loin ? Cross-compiler, ou même debugger à partir de QtCreator ? C'est probablement faisable, mais je n'ai jamais poussé mes expérimentations jusque là. Je pense qu'il faut déclarer un nouveau "Kit" et peut-être des mkspecs adaptés au cross-compilateur et à la cible.
Mais ça commence à faire beaucoup d'infos pour un post de forum !…
Licence ?
La licence (les licences) de Qt ont souvent été source de polémique. Moi-même, j'ai du mal à m'y retrouver …
Heureusement, ça fait longtemps que je n'ai pas eu à me soucier de contrainte commerciale.
Qt est disponible, en libre (comme … vous connaissez la chanson …), pour de nombreuses distributions, ou, pour la version la plus récente, en téléchargement sur le site, et ce, pour tous les environnements habituel (Win, Mac & Linus)
Disclaimer
Non, je ne bosse pas pour Qt ! Promis juré !
Ça fait presque 15 ans que je l'ai découvert, et depuis, je n'ai pas trouvé mieux, c'est tout.
[^] # Re: Un bon compagnon : Qt, qmake & QtCreator
Posté par EdesMerkis . Évalué à 3.
Je me permets d'ajouter que Qt Creator gère très bien les CMakeLists depuis les dernières versions. Tout projet CMake s'ouvre en un clic et on peut modifier les variables définies par cmake directement depuis Qt Creator. Bref pas grand chose à demander de plus.
# et aussi
Posté par riba . Évalué à 4.
GNU global, qui est compatible avec cscope, donc avec vim.
# ctags
Posté par lmg HS (site web personnel) . Évalué à 3.
A noter que exhuberant ctags (celui qui est dispo dans des paquets) n'a plus donné des signes de vie depuis des années. Il n'a jamais été très bon pour le C++ d'ailleurs, mais toujours mieux que cscope.
Heureusement, il y a été forké en universal-ctags, qui lui est maintenu. Il a fait des progrès notables côté C++. Il ne saura pas résoudre pour autant les surcharges automatiquement lorsque l'on voudra l'utiliser pour naviguer vers le lieux où un symbole est défini depuis des outils légers tels que Vim.
Pour ça, il faudra regarder du côté de clang. Il y a plusieurs outils d'indexation et j'avoue ne pas avoir suivi leur état de l'art ces derniers temps pour voir celui qui comprenait le mieux le C++ (toutes versions confondues) tout en n'étant pas trop compliqué à paramétrer.
[^] # Re: ctags
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
Pour vim, j'ai installé youcompleteme, qui communique avec un serveur faisant tourner clang sur les buffers ouverts. On a la complétion, les prototypes des fonctions, et plein d'autres trucs que je découvre petit à petit.
Seul inconvénient: cela mange quelques Go de RAM quand on a des projets un peu complexes, car l'AST (la représentation interne de clang) de chaque fichier est stockée en RAM (cela comprend le fichier + tous les includes).
[^] # Re: ctags
Posté par lmg HS (site web personnel) . Évalué à 1.
Je trouve la configuration de YCM complexe et pas aussi souple que ce que j'aimerai. Typiquement, je bosse sur plusieurs projets en parallèle (produit final + dépendances), et en plus pour chaque projet, je peux choisir le mode (un répertoire en fait) de compilation. Or, avec YCM, c'est l'enfer pour lui dire comment trouver intelligemment, et de façon assez dynamique, où trouver la base de compilation JSON (générée par CMake). Plus des plantages lors de mes dernières utilisations. Ce qui fait qu'au final je suis resté sur ma faim. :(
Après, je sais plus si YCM souffre des mêmes problèmes que les autres outils passant par libclang -> il faut rajouter des chemins que clang connait (!) pour trouver ses propres fichiers d'en-tête…
# Meson ?
Posté par liberforce (site web personnel) . Évalué à 4.
En plus de CMake, je pense qu'évoquer Meson ne ferait pas de mal. Il utilise par défaut un backend Ninja, optionnel sous CMake. Ça gère pkg-config, ça fait les bons choix par défaut (-Wall par exemple), et grâce à Ninja, c'est rapide et ça ne reconstruit que le nécessaire.
Meson
CMake
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Meson ?
Posté par jcelerier . Évalué à 3.
C'est un peu un cas pathologique ton example CMake, il peut se réduire à ça :
Si tu installes le module FindGLib.
Pour énormément de bibliothèques (Qt, SDL, OpenGL, wxWidgets, OpenSceneGraph, libpng, GTK, SFML, BLAS, openssl, etc..) ces modules sont fournis en standard avec CMake et il n'y a rien besoin d'installer, sinon c'est juste un fichier en plus à copier.
# D'autres outils utiles
Posté par jcelerier . Évalué à 3.
Je ne les ai pas vu cités :
# Comparateurs de fichiers
Posté par koopa . Évalué à 1.
Outils graphiques pour comparer des fichiers de manière graphique et fusionner des différences.
meld est mon préféré. C'est le plus intuitif des trois: il ressemble beaucoup au comparateur intégré dans Eclipse.
[^] # Re: Comparateurs de fichiers
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.