Outils utiles pour développeur

58
3
mar.
2017
C et C++

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 \LaTeX) 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 . Évalué à 3 (+2/-0).

    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 (page perso) . Évalué à 8 (+7/-0). Dernière modification le 03/03/17 à 10:41.

    Pourquoi ne mentionner que CLang ?
    Pour les plus curieux, d'autres sont disponibles:

    J'ajouterais:

    • tous les outils de débuggage comme truss ou strace, nm, ltrace, ktrace, kdump et cie.
    • ceux lié au linker (ld), comme ldd.
    • ceux lié à la maintenance patch, diff.
    • [^] # Re: Compilateurs

      Posté par (page perso) . Évalué à 4 (+2/-0).

      Il y en a plein d'autres qui sont libres, par exemple:
      * Open Watcom
      * SDCC (pour l'embarqué, PIC, z80, …)

    • [^] # Re: Compilateurs

      Posté par (page perso) . Évalué à 7 (+7/-1). Dernière modification le 06/03/17 à 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.

  • # git / svn?

    Posté par . Évalué à 2 (+2/-1).

    Les logiciels de gestion de version, est-ce bien nécessaire?

    • [^] # Re: git / svn?

      Posté par (page perso) . Évalué à 1 (+2/-2).

      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 . Évalué à 6 (+7/-2).

        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 . Évalué à 7 (+7/-0).

        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 (page perso) . Évalué à 10 (+10/-0).

        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 . Évalué à 2 (+1/-0).

        Je dirais que c'est indispensable pour les projets qui ont plus d'un développeur.

      • [^] # Re: git / svn?

        Posté par . Évalué à 4 (+1/-0). Dernière modification le 03/03/17 à 16:25.

        Il n'est pas utile pour produire, déverminer ou tester (quoique) son code.

        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)

  • # Un bon compagnon à GDB

    Posté par (page perso) . Évalué à 10 (+11/-0).

    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 (page perso) . Évalué à 5 (+4/-0).

      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.

  • # Petite correction

    Posté par . Évalué à -1 (+0/-2).

    Dans le paragraphe sur Clang :
    licence sans copyleft -> "licence sans copyright" ou "licence copyleft"

    • [^] # Re: Petite correction

      Posté par (page perso) . Évalué à 3 (+3/-1).

      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 . Évalué à 6 (+4/-0).

      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 (page perso) . Évalué à 3 (+1/-1).

      Corrigé, merci.

  • # valgrind --tool=callgrind

    Posté par . Évalué à 8 (+6/-0). Dernière modification le 03/03/17 à 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).

  • # D'autres outils

    Posté par (page perso) . Évalué à 6 (+4/-0).

    Moins connus mais pas forcément moins utiles:

    • m4, un langage de macros pour remplacer des choses dans un fichier texte. Peut être utilisé pour pré-traiter du code source, quand le préprocesseur C montre ses limites, mais aussi pour plein d'autres choses.
    • graphviz, pour faire des graphes.
    • gperf, un outil pour générer une table de hachage sans collisions à partir de chaînes de caractères.

    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 (page perso) . Évalué à 6 (+3/-0).

      Plus pour tester que pour développer :

      • pour de l'XML, xmllint par exemple pour reformater, et xpath (paquet libxml-xpath-perl chez Debian) pour faire des requêtes dessus.
      • pour du JSON, jq pour reformater du JSON et pour faire des requêtes dessus.
  • # Autour du projet

    Posté par (page perso) . Évalué à 5 (+3/-0).

    plantuml Pour la conception.

    kanboard Pour gérer son projet en mode à Gilles.

    taskjuggler Pour gérer ses ressources et son planning sans Gilles.

    http://devnewton.bci.im

  • # CMake n'est pas de plus haut niveau qu'Autotools

    Posté par (page perso) . Évalué à 5 (+5/-0).

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

  • # lint pour l'analyse statique de code

    Posté par . Évalué à 1 (+1/-0).

    Déjà essayé, et c'est vrai qu'il retourne des sources potentiels de bug

  • # cppcheck / jenkins / cppunit

    Posté par . Évalué à 2 (+2/-0).

    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 (page perso) . Évalué à 2 (+0/-0).

      googletest est un cran au dessus de cppunit. Enfin une lib de test unitaire bien conçue !

      • [^] # Re: cppcheck / jenkins / cppunit

        Posté par (page perso) . Évalué à 3 (+2/-0).

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

  • # Défaut de présentation d'un lien hypertexte

    Posté par . Évalué à 2 (+6/-1).

    Dans le premier paragraphe de la section CMake, le lien pour les EDI est mal présenté (mais il fonctionne).

  • # Clang sous Windows ?

    Posté par (page perso) . Évalué à 4 (+3/-0).

    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 . Évalué à 10 (+12/-0).

    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 :

    • HEADERS
    • INCLUDEPATH
    • DEPENDPATH
    • SOURCES
    • OTHER-FILES
    • include()

    Le script suivant, makeQtPro.sh chez moi, est incomplet (il ne gère pas INCLUDEPATH et DEPENDPATH), mais c'est un début :

    !/bin/bash
    
    function makeSection()
    {
    # $1 : section title
    # $2 : section variable
    # $3 : filter
    
    echo
    echo "###########################################################"
    echo "## $1"
    echo
    find . -iname "$3" | sed 's#\./#$$PWD/#' |
        while read file
        do
            echo "$2 += $file"
        done
    echo
    echo
    
    }
    
    makeSection "H files" HEADERS ".h"
    makeSection "HPP files" HEADERS ".hpp"
    
    makeSection "C files" SOURCES ".c"
    makeSection "C++ files" SOURCES ".cpp"
    
    makeSection "ASM files" OTHER_FILES "*.s"
    
    makeSection "Makefiles" OTHER_FILES "Makefile"
    makeSection "Makefiles (continued)" OTHER_FILES "*.mk"
    
    makeSection "Scripts" OTHER_FILES ".sh"
    makeSection "Scripts" OTHER_FILES ".py"
    makeSection "Scripts" OTHER_FILES ".cmd"
    makeSection "Scripts" OTHER_FILES ".bat"

    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 :

    • la modification d'un .pri est détectée. Si la liste des fichiers évolue, recréez votre .pri, et QtCreator suivra le mouvement
    • 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 un Makefile 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 . Évalué à 3 (+3/-0).

      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 . Évalué à 4 (+2/-0).

    GNU global, qui est compatible avec cscope, donc avec vim.

  • # ctags

    Posté par (page perso) . Évalué à 3 (+2/-0).

    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 (page perso) . Évalué à 5 (+3/-0).

      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 (page perso) . Évalué à 1 (+0/-0).

        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 (page perso) . Évalué à 3 (+1/-0).

    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

    project('glib-test', 'c')
    
    deps = dependency ('glib-2.0')
    sources = ['glib-test.c']
    executable('glib-test', sources, dependencies: deps)
    

    CMake

    project (glib-test)
    cmake_minimum_required (VERSION 2.4)
    
    find_package (PkgConfig REQUIRED)
    pkg_check_modules (GLIB2 REQUIRED glib-2.0)
    
    include_directories (${GLIB2_INCLUDE_DIRS})
    link_directories (${GLIB2_LIBRARY_DIRS})
    add_executable (glib-test glib-test.c)
    target_link_libraries (glib-test ${GLIB2_LIBRARIES})
    
    • [^] # Re: Meson ?

      Posté par . Évalué à -1 (+0/-0).

      Bien vu. Tu l'as mentionné aussi ici avec des informations complémentaires (et j'ai fait part de quelques remarques à ta suite).

    • [^] # Re: Meson ?

      Posté par . Évalué à 2 (+2/-0).

      C'est un peu un cas pathologique ton example CMake, il peut se réduire à ça :

      project (glib-test)
      cmake_minimum_required (VERSION 3.6)
      
      find_package (GLib REQUIRED)
      
      add_executable (glib-test glib-test.c)
      target_link_libraries (glib-test PRIVATE glib-2.0)
      

      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 . Évalué à 3 (+3/-0).

    Je ne les ai pas vu cités :

    • Heaptrack : super pour voir l'utilisation mémoire, les allocations, etc.
    • Clazy : plein de checks qui utilisent clang, certains adaptés à un développement avec Qt, d'autres plus généraux pour le C++.
    • GammaRay là encore vachement utile pour le développement Qt, permet de faire énormément d'introspection.
  • # Comparateurs de fichiers

    Posté par . Évalué à 1 (+0/-0).

    Outils graphiques pour comparer des fichiers de manière graphique et fusionner des différences.

    1. meld
    2. diffuse
    3. xxdiff

    meld est mon préféré. C'est le plus intuitif des trois: il ressemble beaucoup au comparateur intégré dans Eclipse.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.