CMakeSettings.json
Informations de référence sur le schéma
Les projets CMake sont pris en charge dans Visual Studio 2017 et versions ultérieures.
Le CMakeSettings.json
fichier contient des informations que Visual Studio utilise pour IntelliSense et pour construire les arguments de ligne de commande qu’il transmet à CMake pour une configuration et un environnement de compilateur spécifiés. Une configuration spécifie les propriétés qui s’appliquent à une plateforme et un type de build spécifiques, par exemple, x86-Debug
ou Linux-Release
. Chaque configuration spécifie un environnement, qui encapsule des informations sur l’ensemble d’outils du compilateur, par exemple MSVC, GCC ou Clang. CMake utilise les arguments de ligne de commande pour régénérer le fichier racine CMakeCache.txt
et d’autres fichiers projet pour le projet. Les valeurs peuvent être substituées dans les CMakeLists.txt
fichiers.
Vous pouvez ajouter ou supprimer des configurations dans l’IDE, puis les modifier directement dans le fichier JSON ou utiliser l’éditeur de Paramètres CMake (Visual Studio 2019 et versions ultérieures). Vous pouvez basculer facilement entre les configurations de l’IDE pour générer les différents fichiers projet. Pour plus d’informations, consultez Personnaliser les paramètres de build CMake dans Visual Studio.
Configurations
Le configurations
tableau contient toutes les configurations d’un projet CMake. Pour plus d’informations sur les configurations prédéfinies, consultez la référence de configuration prédéfinie CMake. Vous pouvez ajouter n’importe quel nombre de configurations prédéfinies ou personnalisées au fichier.
Une configuration
a les propriétés suivantes :
addressSanitizerEnabled
: Sitrue
, compile le programme à l’aide de AddressSanitizer. Sur Linux, compilez avec-fno-omit-frame-pointer
le niveau-Os
d’optimisation du compilateur ou-Oo
pour obtenir de meilleurs résultats.addressSanitizerRuntimeFlags
: indicateurs d’exécution passés à AddressSanitizer dans la variable d’environnementASAN_OPTIONS
. Format : flag1=value :flag2=value2.buildCommandArgs
: spécifie les commutateurs de build natifs passés à CMake après--build --
. Par exemple, le passage-v
lors de l’utilisation du générateur Ninja force Ninja à générer des lignes de commande. Pour plus d’informations sur les commandes Ninja, consultez les arguments de ligne de commande Ninja.buildRoot
: spécifie le répertoire dans lequel CMake génère des scripts de génération pour le générateur choisi. Cartes à-DCMAKE_BINARY_DIR
basculer et spécifie l’emplacement oùCMakeCache.txt
est créé. Si le dossier n’existe pas, il est créé. Les macros prises en charge incluent${workspaceRoot}
,${workspaceHash}
,${projectFile}
,${projectDir}
,${thisFile}
,${thisFileDir}
,${name}
,${generator}
,${env.VARIABLE}
.cacheGenerationCommand
: spécifie un outil en ligne de commande et des arguments, par exemplegencache.bat debug
pour générer le cache. La commande est exécutée à partir de l’interpréteur de commandes dans l’environnement spécifié pour la configuration lorsque l’utilisateur demande explicitement la régénération, ou qu’un ouCMakeSettings.json
unCMakeLists.txt
fichier est modifié.cacheRoot
: spécifie le chemin d’accès à un cache CMake. Ce répertoire doit contenir un fichier existantCMakeCache.txt
.clangTidyChecks
: liste séparée par des virgules des avertissements passés à clang-tidy ; les caractères génériques carte sont autorisés et un préfixe « - » supprime les case activée s.cmakeCommandArgs
: spécifie toutes les options de ligne de commande supplémentaires à passer à CMake lorsqu’elles sont appelées pour générer les fichiers projet.cmakeToolchain
: spécifie le fichier de chaîne d’outils. Il est passé à CMake à l’aide-DCMAKE_TOOLCHAIN_FILE
.codeAnalysisRuleset
: spécifie l’ensemble de règles à utiliser lors de l’exécution de l’analyse du code. Vous pouvez utiliser un chemin d’accès complet ou le nom de fichier d’un jeu de règles installé par Visual Studio.configurationType
: spécifie la configuration du type de build pour le générateur sélectionné. Possibilités :Debug
Release
MinSizeRel
RelWithDebInfo
ctestCommandArgs
: spécifie toutes les options de ligne de commande supplémentaires à passer à CTest lors de l’exécution des tests.description
: description de cette configuration qui apparaît dans les menus.enableClangTidyCodeAnalysis
: Utilisez Clang-Tidy pour l’analyse du code.enableMicrosoftCodeAnalysis
: Utilisez les outils d’analyse de code Microsoft pour l’analyse du code.generator
: spécifie le générateur CMake à utiliser pour cette configuration. Possibilités :Visual Studio 2019 uniquement :
Visual Studio 16 2019
Visual Studio 16 2019 Win64
Visual Studio 16 2019 ARM
Visual Studio 2017 et ultérieur :
Visual Studio 15 2017
Visual Studio 15 2017 Win64
Visual Studio 15 2017 ARM
Visual Studio 14 2015
Visual Studio 14 2015 Win64
Visual Studio 14 2015 ARM
Unix Makefiles
Ninja
Étant donné que Ninja est conçu pour des vitesses de génération rapides au lieu de flexibilité et de fonction, il est défini comme valeur par défaut. Toutefois, certains projets CMake peuvent ne pas pouvoir être générés correctement avec Ninja. Si une défaillance de build se produit, vous pouvez demander à CMake de générer des projets Visual Studio à la place.
Pour spécifier un générateur Visual Studio dans Visual Studio 2017, ouvrez l’éditeur de paramètres dans le menu principal en choisissant CMake | Modifiez le Paramètres CMake. Supprimez « Ninja » et entrez « V ». Cette modification active IntelliSense, ce qui vous permet de choisir le générateur souhaité.
Pour spécifier un générateur Visual Studio dans Visual Studio 2019, cliquez avec le bouton droit sur le CMakeLists.txt
fichier dans Explorateur de solutions et choisissez CMake Paramètres pour le projet>Show Advanced Paramètres> CMake Generator.
Par défaut, lorsque la configuration active spécifie un générateur Visual Studio, elle appelle MSBuild avec -m -v:minimal
des arguments. Pour personnaliser la build, utilisez la buildCommandArgs
propriété à l’intérieur du CMakeSettings.json
fichier. Ici, vous pouvez spécifier des arguments de ligne de commande MSBuild à passer au système de génération :
"buildCommandArgs": "-m:8 -v:minimal -p:PreferredToolArchitecture=x64"
installRoot
: spécifie le répertoire dans lequel CMake génère des cibles d’installation pour le générateur choisi. Les macros prises en charge incluent${workspaceRoot}
,${workspaceHash}
,${projectFile}
,${projectDir}
,${thisFile}
,${thisFileDir}
,${name}
,${generator}
,${env.VARIABLE}
.inheritEnvironments
: spécifie un ou plusieurs environnements de compilateur dont dépend cette configuration. Il peut s’agir de tout environnement personnalisé ou de l’un des environnements prédéfinis. Pour plus d’informations, consultez Environnements.intelliSenseMode
: spécifie le mode utilisé pour l’informatique des informations IntelliSense ». La valeur peut être l’une des suivantes :windows-msvc-x86
windows-msvc-x64
windows-msvc-arm
windows-msvc-arm64
android-clang-x86
android-clang-x64
android-clang-arm
android-clang-arm64
ios-clang-x86
ios-clang-x64
ios-clang-arm
ios-clang-arm64
windows-clang-x86
windows-clang-x64
windows-clang-arm
windows-clang-arm64
linux-gcc-x86
linux-gcc-x64
linux-gcc-arm
name
: nomme la configuration. Pour plus d’informations sur les configurations prédéfinies, consultez la référence de configuration prédéfinie CMake.wslPath
: chemin d’accès au lanceur d’une instance de Sous-système Windows pour Linux.
Paramètres pour les projets Linux CMake
remoteMachineName
: spécifie le nom de la machine Linux distante qui héberge CMake, les builds et le débogueur. Utilisez le gestionnaire de connexions pour l’ajout de nouvelles machines Linux. Les macros prises en charge incluent${defaultRemoteMachineName}
.remoteCopySourcesOutputVerbosity
: spécifie le niveau de détail de l’opération de copie source sur l’ordinateur distant. Peut être l’un desNormal
,Verbose
ouDiagnostic
.remoteCopySourcesConcurrentCopies
: spécifie les copies simultanées à utiliser pendant la synchronisation des sources sur l’ordinateur distant (sftp uniquement).remoteCopySourcesMethod
: spécifie la méthode permettant de copier des fichiers sur l’ordinateur distant. Peut êtrersync
ousftp
.remoteCMakeListsRoot
: spécifie le répertoire sur l’ordinateur distant qui contient le projet CMake. Les macros prises en charge incluent${workspaceRoot}
, ,${workspaceHash}
${projectFile}
,${name}
${projectDir}
${thisFileDir}
${thisFile}
${generator}
et .${env.VARIABLE}
remoteBuildRoot
: spécifie le répertoire sur l’ordinateur distant dans lequel CMake génère des scripts de génération pour le générateur choisi. Les macros prises en charge incluent${workspaceRoot}
,${workspaceHash}
,${projectFile}
,${projectDir}
,${thisFile}
,${thisFileDir}
,${name}
,${generator}
,${env.VARIABLE}
.remoteInstallRoot
: spécifie le répertoire sur l’ordinateur distant dans lequel CMake génère des cibles d’installation pour le générateur choisi. Les macros prises en charge incluent${workspaceRoot}
,${thisFile}
${thisFileDir}
${name}
${generator}
${projectFile}
${projectDir}
${workspaceHash}
et , où${env.VARIABLE}
VARIABLE
est une variable d’environnement qui a été définie au niveau du système, de l’utilisateur ou de la session.remoteCopySources
: quiboolean
spécifie si Visual Studio doit copier des fichiers sources sur l’ordinateur distant. La valeur par défaut est true. Affectez la valeur false si vous gérez vous-même la synchronisation des fichiers.remoteCopyBuildOutput
: quiboolean
spécifie s’il faut copier les sorties de build à partir du système distant.remoteCopyAdditionalIncludeDirectories
: ajout de répertoires include à copier à partir de l’ordinateur distant pour prendre en charge IntelliSense. Mettez en forme « /path1 ;/path2... ».remoteCopyExcludeDirectories
: incluez les répertoires NON à copier à partir de l’ordinateur distant. Mettez en forme « /path1 ;/path2... ».remoteCopyUseCompilerDefaults
: spécifie s’il faut utiliser les définitions par défaut du compilateur et inclure des chemins d’accès pour IntelliSense. Ne doit être false que si les compilateurs en cours d’utilisation ne prennent pas en charge les arguments de style gcc.rsyncCommandArgs
: spécifie un ensemble d’options de ligne de commande passées à rsync.remoteCopySourcesExclusionList
: quiarray
spécifie une liste de chemins à exclure lors de la copie de fichiers sources : un chemin d’accès peut être le nom d’un fichier/répertoire ou un chemin relatif à partir de la racine de la copie. Wild carte s*
et?
peut être utilisé pour la mise en correspondance des modèles glob.cmakeExecutable
: spécifie le chemin complet de l’exécutable du programme CMake, y compris le nom de fichier et l’extension.remotePreGenerateCommand
: spécifie la commande à exécuter avant d’exécuter CMake pour analyser leCMakeLists.txt
fichier.remotePrebuildCommand
: spécifie la commande à exécuter sur l’ordinateur distant avant la génération.remotePostbuildCommand
: spécifie la commande à exécuter sur l’ordinateur distant après la génération.variables
: contient une paire nom-valeur de variables CMake qui sont transmises en tant que-D name=value
CMake. Si vos instructions de génération de projet CMake spécifient l’ajout de toutes les variables directement au fichier, nous vous recommandons de les ajouter ici à laCMakeCache.txt
place. Cet exemple montre comment spécifier les paires nom-valeur pour utiliser l’ensemble d’outils MSVC 14.14.26428 :
"variables": [
{
"name": "CMAKE_CXX_COMPILER",
"value": "C:/Program Files (x86)/Microsoft Visual Studio/157/Enterprise/VC/Tools/MSVC/14.14.26428/bin/HostX86/x86/cl.exe",
"type": "FILEPATH"
},
{
"name": "CMAKE_C_COMPILER",
"value": "C:/Program Files (x86)/Microsoft Visual Studio/157/Enterprise/VC/Tools/MSVC/14.14.26428/bin/HostX86/x86/cl.exe",
"type": "FILEPATH"
}
]
Si vous ne définissez pas le "type"
type, le "STRING"
type est supposé par défaut.
remoteCopyOptimizations
: Propriétés Visual Studio 2019 version 16.5 ou ultérieures pour contrôler la copie source vers la cible distante. Les optimisations sont activées par défaut. InclutremoteCopyUseOptimizations
,rsyncSingleDirectoryCommandArgs
etremoteCopySourcesMaxSmallChange
.
Environnements
Un environnement encapsule les variables d’environnement définies dans le processus que Visual Studio utilise pour appeler CMake. Pour les projets MSVC, il capture les variables définies dans une invite de commandes développeur pour une plateforme spécifique. Par exemple, l’environnement msvc_x64_x64
est identique à l’exécution de l’invite de commandes développeur pour VS {version} avec les arguments -arch=amd64 -host_arch=amd64 . Vous pouvez utiliser la env.{<variable_name>}
syntaxe pour CMakeSettings.json
référencer les variables d’environnement individuelles, par exemple pour construire des chemins d’accès aux dossiers. Les environnements prédéfinis suivants sont fournis :
linux_arm
: Ciblez LINUX ARM à distance.linux_x64
: Cible x64 Linux à distance.linux_x86
: Ciblez linux x86 à distance.msvc_arm
: Ciblez Windows ARM avec le compilateur MSVC.msvc_arm_x64
: Ciblez Windows ARM avec le compilateur MSVC 64 bits.msvc_arm64
: Ciblez ARM64 Windows avec le compilateur MSVC.msvc_arm64_x64
: Ciblez ARM64 Windows avec le compilateur MSVC 64 bits.msvc_arm64ec
: ciblez ARM64EC Windows avec le compilateur MSVC.msvc_arm64ec_x64
: Ciblez ARM64EC Windows avec le compilateur MSVC 64 bits.msvc_x64
: Ciblez x64 Windows avec le compilateur MSVC.msvc_x64_x64
: Ciblez x64 Windows avec le compilateur MSVC 64 bits.msvc_x86
: Ciblez x86 Windows avec le compilateur MSVC.msvc_x86_x64
: Ciblez x86 Windows avec le compilateur MSVC 64 bits.
Accès aux variables d’environnement à partir de CMakeLists.txt
À partir d’un fichier, toutes les variables d’environnement CMakeLists.txt
sont référencées par la syntaxe $ENV{variable_name}
. Pour afficher les variables disponibles pour un environnement, ouvrez l’invite de commandes correspondante et tapez SET
. Certaines des informations contenues dans les variables d’environnement sont également disponibles via les variables d’introduction au système CMake, mais vous pouvez trouver plus pratique d’utiliser la variable d’environnement. Par exemple, vous pouvez facilement récupérer la version du compilateur MSVC ou la version du Kit de développement logiciel (SDK) Windows via les variables d’environnement.
Variables d’environnement personnalisées
Dans CMakeSettings.json
, vous pouvez définir des variables d’environnement personnalisées globalement ou par configuration dans le environments
tableau. Un environnement personnalisé est un moyen pratique de regrouper un ensemble de propriétés. Vous pouvez l’utiliser à la place d’un environnement prédéfini, ou pour étendre ou modifier un environnement prédéfini. Chaque élément dans le tableau environments
comprend ce qui suit :
namespace
: nomme l’environnement afin que ses variables puissent être référencées à partir d’une configuration au formatnamespace.variable
. L’objet environnement par défaut est appeléenv
et il est rempli avec certaines variables d’environnement système, notamment%USERPROFILE%
.environment
: identifie de façon unique ce groupe de variables. Permet au groupe d’être hérité plus tard dans une entréeinheritEnvironments
.groupPriority
: entier qui spécifie la priorité de ces variables lors de leur évaluation. Les éléments dont la valeur est élevée sont évalués en premier.inheritEnvironments
: tableau de valeurs qui spécifient l’ensemble d’environnements hérités par ce groupe. Cette fonctionnalité vous permet d’hériter des environnements par défaut et de créer des variables d’environnement personnalisées à passer à CMake lors de son exécution.
Visual Studio 2019 version 16.4 et ultérieure : les cibles de débogage sont automatiquement lancées avec l’environnement dans CMakeSettings.json
lequel vous spécifiez . Vous pouvez remplacer ou ajouter des variables d’environnement par cible ou par tâche dans launch.vs.json
et tasks.vs.json
.
L’exemple suivant définit une variable globale, BuildDir
héritée à la fois dans les configurations x86-Debug et x64-Debug. Chaque configuration utilise la variable pour spécifier la valeur de la buildRoot
propriété pour cette configuration. Notez également comment chaque configuration utilise la inheritEnvironments
propriété pour spécifier une variable qui s’applique uniquement à cette configuration.
{
// The "environments" property is an array of key-value pairs of the form
// { "EnvVar1": "Value1", "EnvVar2": "Value2" }
"environments": [
{
"BuildDir": "${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\\build",
}
],
"configurations": [
{
"name": "x86-Debug",
"generator": "Ninja",
"configurationType": "Debug",
// Inherit the defaults for using the MSVC x86 compiler.
"inheritEnvironments": [ "msvc_x86" ],
"buildRoot": "${env.BuildDir}\\${name}" },
{
"name": "x64-Debug",
"generator": "Ninja",
"configurationType": "Debug",
// Inherit the defaults for using the MSVC x64 compiler.
"inheritEnvironments": [ "msvc_x64" ],
"buildRoot": "${env.BuildDir}\\${name}"
}
]
}
Dans l’exemple suivant, la configuration x86-Debug définit sa propre valeur pour la propriété BuildDir. Cette valeur remplace celle définie par la propriété BuildDir globales pour que BuildRoot prenne la valeur D:\custom-builddir\x86-Debug
.
{
"environments": [
{
"BuildDir": "${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}",
}
],
"configurations": [
{
"name": "x86-Debug",
// The syntax for this property is the same as the global one above.
"environments": [
{
// Replace the global property entirely.
"BuildDir": "D:\\custom-builddir"
// This environment does not specify a namespace, hence by default "env" is assumed.
// "namespace" : "name" would require that this variable be referenced with "${name.BuildDir}".
}
],
"generator": "Ninja",
"configurationType": "Debug",
"inheritEnvironments": [ "msvc_x86" ],
// Evaluates to "D:\custom-builddir\x86-Debug"
"buildRoot": "${env.BuildDir}\\${name}"
},
{
"name": "x64-Debug",
"generator": "Ninja",
"configurationType": "Debug",
"inheritEnvironments": [ "msvc_x64" ],
// Since this configuration doesn't modify BuildDir, it inherits
// from the one defined globally.
"buildRoot": "${env.BuildDir}\\${name}"
}
]
}
Macros
Les macros suivantes peuvent être utilisées dans CMakeSettings.json
:
${workspaceRoot}
: chemin d’accès complet du dossier de l’espace de travail${workspaceHash}
: Hachage de l’emplacement de l’espace de travail. Utile pour créer un identificateur unique pour l’espace de travail actuel (par exemple, à utiliser dans les chemins de dossier)${projectFile}
: chemin d’accès complet du fichier racineCMakeLists.txt
${projectDir}
: chemin d’accès complet du dossier contenant le fichier racineCMakeLists.txt
${projectDirName}
: nom du dossier contenant le fichier racineCMakeLists.txt
${thisFile}
: chemin d’accès complet duCMakeSettings.json
fichier${name}
: Nom de la configuration${generator}
: Nom du générateur CMake utilisé dans cette configuration
Toutes les références aux macros et variables d’environnement sont CMakeSettings.json
développées avant d’être passées à la ligne de commande CMake.
Arguments de ligne de commande Ninja
Si les cibles ne sont pas spécifiées, Ninja génère la cible « par défaut ».
C:\Program Files (x86)\Microsoft Visual Studio\Preview\Enterprise>ninja -?
ninja: invalid option -- `-?'
usage: ninja [options] [targets...]
Option | Description |
---|---|
--version |
Imprimer la version ninja (« 1.7.1 ») |
-C DIR |
Passer à DIR avant d’effectuer autre chose |
-f FILE |
Spécifier le fichier de build d’entrée (default=build.ninja ) |
-j N |
Exécuter des N travaux en parallèle (par défaut=14, dérivé de processeurs disponibles) |
-k N |
Continuez jusqu’à ce que N les travaux échouent (par défaut=1) |
-l N |
Ne démarrez pas de nouveaux travaux si la moyenne de charge est supérieure à N |
-n |
Exécution sèche (n’exécutez pas de commandes, mais agissez comme elles ont réussi) |
-v |
Afficher toutes les lignes de commande lors de la génération |
-d MODE |
Activer le débogage (utiliser -d list pour répertorier les modes) |
-t TOOL |
Exécutez un sous-outil (utilisez -t list pour répertorier les sous-outils). Termine toutes les options de niveau supérieur ; d’autres indicateurs sont passés à l’outil |
-w FLAG |
Ajuster les avertissements (utiliser -w list pour répertorier les avertissements) |