Outils utiles pour développeur

Posté par Eiffel le 03 mars 2017 à 10:02. Édité par Davy Defaud, Lucas, kp, palm123, Benoît Sibaud, Tonton Th, BAud, Nÿco, Jehan, RyDroid, Nils Ratusznik, ZeroHeure, Jiehong, ɹǝıʌıʃO, Pierre Jarillon et Storm. Modéré par Pierre Jarillon. Licence CC By‑SA.

Étiquettes :

mar.

2017

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.

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 Eiffel le 03 mars 2017 à 10:36. É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 (site web personnel) le 03 mars 2017 à 10:37. Évalué à 8. Dernière modification le 03 mars 2017 à 10:41.
Pourquoi ne mentionner que CLang ?
Pour les plus curieux, d'autres sont disponibles:
- Portable C Compiler ;
- Tiny C compiler;
- Et d'autres, propriétaires.
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 pulkomandy (site web personnel, Mastodon) le 03 mars 2017 à 12:40. É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) le 06 mars 2017 à 12:16. É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) le 06 mars 2017 à 15:19. Évalué à 0.
    
    (Quelle horreurs ces fautes, et je ne peux plus éditer mon message :-( )
# git / svn?

Posté par Anonyme le 03 mars 2017 à 10:43. Évalué à 2.

Les logiciels de gestion de version, est-ce bien nécessaire?
- [^] # Re: git / svn?
  
  Posté par David Marec (site web personnel) le 03 mars 2017 à 10:59. É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 le 03 mars 2017 à 11:03. É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 le 03 mars 2017 à 11:06. É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) le 03 mars 2017 à 12:43. É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 le 03 mars 2017 à 13:02. É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) le 03 mars 2017 à 15:04. É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 le 03 mars 2017 à 16:23. Évalué à 4. Dernière modification le 03 mars 2017 à 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)
    - [^] # Re: git / svn?
      
      Posté par DerekSagan le 04 mai 2017 à 16:30. Évalué à 2.
      
      ni même git log
# Un bon compagnon à GDB

Posté par Adrien BUSTANY (site web personnel) le 03 mars 2017 à 11:18. É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) le 03 mars 2017 à 11:21. É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) le 03 mars 2017 à 11:54. Évalué à 2.
    
    Corrigé, merci.
# Petite correction

Posté par Jona le 03 mars 2017 à 11:19. É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) le 03 mars 2017 à 11:31. É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) le 03 mars 2017 à 11:33. É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) le 03 mars 2017 à 11:53. Évalué à 3.
  
  Corrigé, merci.
# valgrind --tool=callgrind

Posté par rewind (Mastodon) le 03 mars 2017 à 11:36. É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 le 03 mars 2017 à 13:18. É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 le 06 mars 2017 à 10:26. É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) le 03 mars 2017 à 12:48. Évalué à 6.
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 Benoît Sibaud (site web personnel) le 03 mars 2017 à 13:12. Évalué à 6.
  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 devnewton 🍺 (site web personnel) le 03 mars 2017 à 13:09. É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) le 03 mars 2017 à 13:40. É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 le 04 mars 2017 à 13:50. Évalué à 3.
  
  Phabricator a l'air très complet.
  - [^] # Re: Autour du projet
    
    Posté par DerekSagan le 05 mars 2017 à 12:13. É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) le 03 mars 2017 à 14:52. É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) le 04 mars 2017 à 13:48. Évalué à 3.
  
  Corrigé, merci.
# lint pour l'analyse statique de code

Posté par podoc le 03 mars 2017 à 17:00. É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 le 06 mars 2017 à 15:57. É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 le 04 mars 2017 à 09:01. É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) le 04 mars 2017 à 22:08. É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) le 06 mars 2017 à 11:40. É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 le 04 mars 2017 à 09:37. É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) le 04 mars 2017 à 13:46. Évalué à 2.
  
  Corrigé, merci.
# Clang sous Windows ?

Posté par Tarnyko (site web personnel) le 04 mars 2017 à 11:31. É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 le 05 mars 2017 à 00:13. É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 :
- 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 EdesMerkis le 05 mars 2017 à 11:42. É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 le 05 mars 2017 à 18:12. Évalué à 4.

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

Posté par lmg HS (site web personnel) le 06 mars 2017 à 11:49. É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) le 06 mars 2017 à 13:17. É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) le 06 mars 2017 à 15:16. É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) le 10 mars 2017 à 17:52. É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
```
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})
```
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 10 mars 2017 à 23:20. Évalué à -1.
  
  Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: Meson ?
  
  Posté par jcelerier le 22 mars 2017 à 00:04. Évalué à 3.
  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 jcelerier le 21 mars 2017 à 23:57. Évalué à 3.
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 koopa le 23 mars 2017 à 13:53. Évalué à 1.
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.
- [^] # Re: Comparateurs de fichiers
  
  Posté par Benoît Sibaud (site web personnel) le 23 mars 2017 à 14:09. Évalué à 5.
  - vimdiff