IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

CLion 2019.2 disponible, l'EDI C/C++ de JetBrains apporte des améliorations pour le développement embarqué
Et un débogueur expérimental MSVC

Le , par Michael Guilloux

277PARTAGES

15  0 
Fin mars, JetBrains a annoncé la sortie de CLion 2019.1, la première mise à jour majeure annuelle de son EDI C/C++ pour Linux, macOS et Windows intégré au système de génération CMake. Celle-ci apportait un bon lot de fonctionnalités et améliorations. Parmi les plus notables, rappelons que CLion 2019.1 a fait quelques pas vers le développement embarqué. À part cela, ses refactorings C++ sont désormais plus précis et la mise en surbrillance du code a été transférée à Clangd pour rendre l'éditeur plus réactif. Pour vous aider aussi à suivre votre style de codage préféré, on note dans la version 2019.1 que CLion s’intègre maintenant au célèbre outil ClangFormat et ajoute la prise en charge de divers schémas de nommage C/C++.

JetBrains vient de publier CLion 2019.2, la deuxième mise à jour majeure de l'année de son EDI C/C++, qui apporte aussi bon nombre de nouveautés : améliorations pour le développement embarqué et ajout de nouvelles capacités de débogage, notamment un débogueur expérimental pour la chaîne d'outils Microsoft Visual C++. CLion 2019.2 embarque en outre des nouveautés pour faciliter l'édition de code, des performances améliorées, entre autres.

Développement embarqué

JetBrains a commencé à travailler sur le support du développement embarqué dans CLion, comme en témoignait la version 2019.1. Dans cette nouvelle itération, l'éditeur de logiciels pour les développeurs continue dans la même lancée avec une large gamme de capacités de débogage sur puce et un nouvel onglet Périphériques.

Débogage sur puce avec GDB Server

Pour le débogage sur puce, vous pouviez déjà utiliser le débogueur OpenOCD fourni dans la version 2019.1. Rappelons qu’OpenOCD (Open On-Chip Debugger) est un outil open source pour le débogage de microcontrôleurs. Mais la liste des débogueurs se rallonge dans CLion 2019.2. Si votre microcontrôleur prend en charge le débogage via un serveur GDB, vous pouvez maintenant le faire dans CLion. Cela signifie que pour OpenOCD, les serveurs GDB ST-Link, le serveur GDB Segger J-Link, QEMU et de nombreux autres serveurs GDB spécifiques, vous pouvez les exécuter à partir de CLion et bénéficier des capacités de débogage intégrées fournies par CLion. Tout ce que vous avez à faire est de fournir les paramètres dans la configuration Run/Debug "Embedded GDB Server" qui a été récemment ajoutée :


Configurez le chemin d'accès au serveur GDB personnalisé, les arguments spécifiques au serveur GDB (par exemple, le numéro de port ou un fichier de configuration de la carte) et, si nécessaire, le répertoire de travail, les variables d'environnement, la commande de réinitialisation de la carte et le délai de démarrage. Notez que, comme pour la configuration Run/Debug OpenOCD, cette nouvelle configuration fonctionne uniquement avec les projets basés sur CMake pour le moment. Mais à l'avenir, JetBrains prévoit d'ajouter la possibilité de lancer ces configurations pour les cibles personnalisées (Custom Targets).

Une vue Périphériques pour les périphériques ARM

Pour les périphériques ARM, il y a souvent une vue Périphériques spécifiée décrite dans le fichier .svd pour votre type de microcontrôleur. CLion offre maintenant un moyen pratique de lire ces valeurs dans l’onglet Périphériques dédié de la fenêtre de l’outil de débogage :


Il fonctionne avec les configurations "Embedded GDB Server" et "OpenOCD Download & Run" et est disponible lorsqu'un ou plusieurs fichiers .svd sont chargés. En outre, il est utile de savoir que vous pouvez effectuer une recherche dans la vue Périphériques (il suffit de commencer à saisir le nom que vous recherchez), exporter la vue au format CSV ou l’ouvrir dans l’éditeur pour une recherche ultérieure.

Nouveautés pour le débogueur

On note des améliorations relatives à GDB, le débogueur standard du projet GNU : CLion 2019.2 est en effet livrée avec GDB 8.3 et introduit une nouvelle série de correctifs pour le débogueur en vue d'améliorer l'expérience utilisateur.

Comme autre nouveauté, on peut citer la complétion pour les commandes GDB/LLDB. Précisons que LLDB (Low Level Debugger), est un débogueur pour les langages de programmation Objective-C, C++ et C et constitue un sous-projet de LLVM. Si vous devez utiliser l'interface de ligne de commande pour GDB/LDB, vous pouvez désormais le faire facilement dans CLion.

C'est sans doute l'une des fonctionnalités les plus importantes de cette version : CLion 2019.2 vient avec un débogueur expérimental pour la chaîne d'outils Microsoft Visual C++ (MSVC)


Il convient de dire quelques mots sur la technologie sur laquelle repose ce débogueur expérimental. Pour le code compilé avec le compilateur Microsoft Visual C++, plusieurs moteurs de débogage sont disponibles dans différents outils. Dans les outils Microsoft, c'est le moteur vsdebugeng.dll qui est utilisé, mais il n’est pas disponible pour d’autres outils en raison des limitations de licence. Les outils de débogage pour Windows CDB et WinGDB, quant à eux, utilisent le moteur dbgeng.dll.

Initialement, JetBrains a essayé de créer un débogueur au-dessus de ce moteur. Mais plusieurs problèmes ont été rencontrés, notamment des crashs et des performances médiocres sur des fichiers binaires volumineux comportant de nombreux PDB. Cela a poussé JetBrains à explorer une autre option : l’implémentation d’un débogueur au-dessus de LLDB, et ça a marché. Il reste encore beaucoup de travail à faire, mais JetBrains est plutôt optimiste à propos de son débogueur. Basé sur LLDB, il peut fonctionner avec les visualiseurs natifs issus de l'installation de Visual Studio ou de votre projet.

Une autre nouveauté concerne la vue Mémoire. La vue mémoire vous aide à visualiser la mémoire brute du processus en cours lors du débogage. Dans la version 2019.2, plusieurs mises à jour ont été apportées à celle-ci. Par exemple, vous pouvez accéder à une adresse particulière dans la mémoire à partir de la vue Mémoire, grâce à une nouvelle capacité appelée "Go to address". Dans la vue Mémoire, un nouveau champ "Go to" a en effet été ajouté. Il suffit d'indiquer une adresse (en hexadécimal), un nom de variable ou appeler son adresse via "&" pour passer à l'adresse correspondante :


Nouveautés dans l'éditeur

La vérification (check) "Unused Includes" est de retour et est plus précise. La vérification "Unused Includes" a été désactivée pendant un certain temps en raison des multiples faux positifs qu’elle a provoqués. Maintenant, JetBrains l'a complètement réimplémentée au-dessus de Clang et l'a réactivée par défaut. Soulignons aussi que Clang-Tidy (un outil de vérification de code) a été mis à jour vers une version plus récente de Clang, ce qui lui permet d'apporter un ensemble de nouvelles vérifications à CLion.

CLion 2019.2 affiche aussi des indications sur les noms des paramètres pour faciliter la lecture de votre code. Vous avez probablement déjà consulté un appel de fonction avec des paramètres tels que ‘true, false, true’ ou ‘10, 20, 30’ et avez essayé de deviner ce que chaque élément signifiait. Vous pouvez bien sûr accéder à la déclaration de fonction, consulter la documentation rapide ou appeler les informations sur les paramètres, mais vous voulez obtenir ces informations encore plus rapidement. C'est là qu'entrent en jeu les indications sur les noms de paramètres. Pour les appels de fonction, les lambdas, les constructeurs, les listes d'initialiseur et les expressions de macro, CLion affiche désormais les noms des paramètres pour les arguments transmis. Cela fonctionne si un argument est un littéral ou une expression avec plusieurs opérandes.

Comme autre nouveauté au niveau de l'édition de code, citons encore l'assistance de code dans les fichiers de configuration ClangFormat. L'outil ClangFormat est largement utilisé dans le monde C/C++ et est même considéré comme un standard par de nombreux développeurs. Dans CLion, il a été ajouté en tant que formateur de code alternatif dans la version 2019.1. Depuis, JetBrains dit avoir constaté que les utilisateurs ont tendance à mettre à jour les fichiers de configuration .clang-format dans leurs projets dans CLion. C’est pourquoi l'éditeur de logiciels leur a ajouté cette nouveauté : CLion complète le nom des options et leurs valeurs, en affichant la description de l’option dans la fenêtre de complétion, alors que la documentation rapide fournit la documentation d'origine avec des exemples.


Autres nouveautés et améliorations

Amélioration des performances

JetBrains fait de la performance l'une de ses priorités dans les différentes versions de CLion, mais souvent les modifications nécessitent plus de travail et peuvent même affecter la manière dont CLion interagit avec la plateforme IntelliJ. Toutefois, des améliorations de performances pour l'EDI arrivent dans chaque version. Dans CLion 2019.2, on note par exemple que la refactorisation "Rename" sur place (in-place Rename) a été retravaillée pour éliminer les retards et les blocages. Les performances de la complétion de code pour les expressions qualifiées dans l'éditeur ont également été considérablement améliorées. En outre, la collecte d'informations du compilateur et le chargement de l'étape CMake dans des cas distants ont été accélérés en réduisant le nombre d'opérations d'entrée/sortie. Précisons aussi que CLion vous avertit maintenant lorsque Windows Defender affecte les performances de build et peut exclure automatiquement les répertoires de l'analyse en temps réel du logiciel de sécurité.

Coloration syntaxique pour plus de 20 nouveaux langages

Il y a souvent du code provenant d'autres langages de programmation dans votre projet C ou C++. Python, JavaScript, HTML, XML et SQL sont tous inclus dans CLion. Et il existe un plugin pratique pour Rust. Mais qu'en est-il des autres qui ne sont pas aussi populaires dans le monde C++, mais qui sont toujours utilisés ? Par exemple, Ruby et C#. Dans la version 2019.2, JetBrains a ajouté la coloration syntaxique pour plus de 20 langages de programmation différents, et tout fonctionne immédiatement. Aucune configuration supplémentaire n'est requise, grâce à la collection de fichiers de grammaire linguistique de TextMate fournie avec l'EDI.

Support des scripts Shell

Lorsqu'on parle de langages complémentaires dans les projets C et C++, les scripts shell sont naturels pour la majorité de ces projets. Il n’est pas inhabituel de générer du code ou effectuer d'autres actions dans de tels scripts. L’assistance à l'édition de code dans les scripts shell peut donc vous aider à augmenter votre productivité. C’est pourquoi, avec CLion 2019.2, JetBrains offre un plugin de script Shell, qui fournit des fonctionnalités utiles telles que la coloration syntaxique du code, la complétion des mots et des chemins, entre autres. Cela rend donc l'écriture de script Shell plus facile. Et vous pouvez vérifier les scripts directement dans l'EDI, en les exécutant dans le terminal intégré.


Mise à jour du plugin Rust

Le plugin Rust a été mis à jour de manière significative dans cette version, une mise à jour qui permet d'activer des fonctionnalités telles que la coloration, la résolution de noms et la complétion pour les modules générés, etc.


Télécharger CLion 2019.2

Voir aussi :

WebStorm 2019.2 disponible : tour d'horizon des nouveautés de l'EDI de JetBrains pour les développeurs JavaScript
IntelliJ IDEA 2019.2 apporte des fonctionnalités en préversion de Java 13, des outils de profilage et bien plus encore
CLion 2019.1 disponible : l'EDI C/C++ vient avec un meilleur support du développement embarqué, ClangFormat comme formateur de code alternatif et plus
Python en 2018, les chiffres clés de la communauté : EDI, frameworks, utilisation, SGBD, ORM, tests...
La version 2019.2 de YouTrack, le logiciel de gestion de projet et de suivi des incidents est disponible et peut être désormais connecté à Bitbucket

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de grunk
Modérateur https://www.developpez.com
Le 01/08/2019 à 14:20
Citation Envoyé par Matthieu76 Voir le message
Si c'est pour compiler avec MSVC pourquoi ne pas directement utiliser Visual Studio 2019 ?
C'est le cas aujourd'hui (en 2015) , mais je travail aussi sous linux avec Clion , en java avec intellij et en web avec phpstorm. Donc si je pouvais ne pas avoir à endurer visual ça m'arrangerait
Je pourrais entre autre
- arrêter de devoir faire des SOURCE_GROUP dans tous les fichiers cmake et travailler avec la véritable arborescence du projet ....)
- ne plus freeze pendant 30 sec sans raison apparente après un scroll ou une prise de focus sur l'ide
- avoir une recherche d'utilisation de code qui fonctionne et qui ne me retourne pas n'importe quoi.
bref me séparer de tous les truc qui me gonfle dans visual
6  0 
Avatar de Bktero
Modérateur https://www.developpez.com
Le 01/08/2019 à 19:57
La vue avec le contenu de la mémoire et surtout celle avec les registres du micro-contrôleur, on en a rêvé avec des collègues

Si c'est pour compiler avec MSVC pourquoi ne pas directement utiliser Visual Studio 2019 ?
Les deux sont disponibles sous windows (gcc sous windows == MinGW-w64 ), et, si tu utilise CMake (que ce soit avec CLion ou n'importe quel autre EDI), cela ne te posera pas énormément de problème
Je vais vous donner l'exemple de mon ancien projet et ça répondra à vos 2 questions d'un coup :
- ta cible est un micro-contrôleur ARM et tu as une toolchain arm-gcc-none-eabi
- tu utilises une bibliothèque graphique embarqué
- tu fais tout ça dans CLion
- tu veux simuler ton IHM
- la bibliothèque graphique fournie uniquement une DLL de simulateur pour Visual Studio --> tu peux pas faire de mingw
- tu ne veux pas maintenir 2 builds et / ou switcher d'IDE --> tu veux tout faire dans CLion

Quand tu fais tout fonctionner, tu as limite droit à une ovation en daily meeting :mgreen:
3  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 30/07/2019 à 9:00
Quelqu'un à reussi à activer le debug sous visual ?

Chez moi la fonctionnalité expérimental à activer (cidr.debugger.lldb.windows) n'existe pas dans la fenêtre des "Experimental Features".

Et accessoirement quelqu'un à déjà réussi à compiler sous windows en multi thread ? A priori nmake ne le supporte pas du coup c'est monothread ... autant dire pas envisageable pour moi.
2  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 01/08/2019 à 15:50
Salut,
Citation Envoyé par grunk Voir le message
C'est le cas aujourd'hui (en 2015) , mais je travail aussi sous linux avec Clion , en java avec intellij et en web avec phpstorm. Donc si je pouvais ne pas avoir à endurer visual ça m'arrangerait
Je pourrais entre autre
- arrêter de devoir faire des SOURCE_GROUP dans tous les fichiers cmake et travailler avec la véritable arborescence du projet ....)
- ne plus freeze pendant 30 sec sans raison apparente après un scroll ou une prise de focus sur l'ide
- avoir une recherche d'utilisation de code qui fonctionne et qui ne me retourne pas n'importe quoi.
bref me séparer de tous les truc qui me gonfle dans visual
Mais, dans ce cas, pourquoi ne te tournerais tu pas vers Gcc ou vers CLang comme compilateur

Les deux sont disponibles sous windows (gcc sous windows == MinGW-w64 ), et, si tu utilise CMake (que ce soit avec CLion ou n'importe quel autre EDI), cela ne te posera pas énormément de problème

La seule chose qui soit réellement intéressante avec Visual, c'est son debuggeur, qui est bien mieux intégré (du moins, qui l'était, fut un temps )que ne l'est gdb dans la plupart des EDI

Personnellement, bien que je n'utilise pas CLion (mais j'utilise CMake ), je développe généralement mon code "à l'ancienne" (une ligne de commande ouverte, un simple éditeur de texte plats) sous linux, avant de passer sous windows et de le compiler avec mingw et / ou clang, pour terminer par un test sous visual studio...quand j'y pense ... Et cela me va très bien
0  0 
Avatar de Matthieu76
Membre éclairé https://www.developpez.com
Le 01/08/2019 à 10:09
Si c'est pour compiler avec MSVC pourquoi ne pas directement utiliser Visual Studio 2019 ?
0  1