Système de build C/C++: j'utilise XMake
Ce post est une traduction d'un article écrit par l'auteur de XMake (avec son accord) explicant les raisons de la création de XMake et son intérêt. Je n'ai fait que traduire, relire (partiellement à l'aide de l'excellent deepl.com) et réécrire certains passages (l'auteur n'étant pas anglophone) sans en changer le sens.
Qu'est-ce que XMake ?
XMake est un système de compilation C/C++ moderne basé sur Lua.
Sa grammaire est concise et facile à utiliser, conviviale pour les novices, même si vous ne connaissez pas du tout Lua, vous pouvez démarrer rapidement, et il est complètement libre de toute dépendance, léger et multiplateforme.
Dans le même temps, c'est aussi un système de compilation tout compris avec un puissant système de gestion de paquets et un système de compilation rapide.
Il se compare à Ninja/Scons/Make en tant que backend de compilation[1], CMake/Meson en tant que générateur de projet[2]. XMake s'occupe non seulement d'être un backend de compilation et générateur de projet en même temps mais dispose également d'un gestionnaire de dépendances intégré.
xmake = Backend de compilation + Générateur de projet + Gestionnaire de dépendances
(NDT: Depuis l'écriture de l'article original, XMake peut également gérer la compilation distribuée et le cache de compilation)
Par conséquent, il vous suffit d'installer un paquet d'installation XMake de moins de 3mo, et vous n'avez pas besoin d'installer d'autres outils. Vous n'avez même pas besoin d'installer make, ni d'installer des environnements d'exécution lourds tels que Python et Java. Vous pouvez rapidement commencer à développer en C/C++.
Certains vous diront peut-être qu'il faut toujours installer le compilateur. Ce n'est pas forcément nécessaire, car la gestion des paquets de XMake permet également d'extraire automatiquement des outils de compilation, tels que LLVM, Mingw, le NDK Android NDK, emscripten, etc.
Pourquoi avoir créé XMake
Lorsque je parle de XMake avec d'autres développeurs sur Reddit, bien souvent je reçoit l'image suivant en réponse :
Bien que ces réponses me font me sentir un peu désemparé, je tiens à expliquer que l'intention originale de XMake n'était pas de diviser l'écosystème C/C++. Au contraire, XMake réutilise les outils existants autant que possible.
Dans le même temps, il permet aux utilisateurs d'avoir la même expérience que d'autres langages modernes lorsqu'ils développent des projets C/C++, tels que Rust/Cargo, Nodejs/Npm, Dlang/Dub, au lieu d'être embêté dès lors qu'il faut intégrer une bibliothèque et étudier comment compiler sur chaque plateforme.
Par conséquent, si vous ne connaissez pas XMake, ne tirez pas de conclusions trop hâtives, vous pouvez d'abord l'essayer, ou prendre un moment pour lire l'introduction détaillée ci-dessous.
Caractéristiques et avantages de XMake
Les gens me demandent souvent ce que XMake a de particulier et quels sont ses avantages par rapport aux outils de compilation existants tels que CMake et Meson. Pourquoi devrais-je utiliser XMake plutôt que CMake ?
Permettez-moi d'abord de parler des caractéristiques et des avantages de XMake :
- Syntaxe de configuration concise et facile à apprendre, sans langage propre (NDT: pas de DSL = langage qui n'est utilisé que pour XMake).
- Gestion puissante des dépendances, support de la version sémantique, gestion des outils de compilation.
- Assez léger, pas de dépendance
- Rapide, la compilation est aussi rapide qu'avec Ninja
- Changement de plateforme (NDT: Windows/Linux/iOS/Android/etc.) et d'outils de compilation simple et pratique
- Système complet de plugins
- Règles de compilation flexibles
XMake peut être utilisé comme un complément pour les nouveaux arrivants qui souhaitent un démarrage simple et rapide du développement C/C++, ou qui veulent une gestion des dépendances plus pratique et plus facile à utiliser, ou qui veulent écrire rapidement de petits projets de test temporaires.
XMake peut les aider à améliorer l'efficacité du développement et leur permettre d'accorder plus d'attention au projet C/C++ lui-même plutôt que de passer plus de temps à construire des outils et des environnements de développement.
Présentons maintenant les principales fonctionnalités de XMake en détail :
Syntaxe simple
CMake a conçu un langage propre pour la configuration des projets, ce qui augmente les coûts d'apprentissage pour les utilisateurs, et sa syntaxe n'est pas très intuitive, il est facile d'écrire des scripts de configuration trop complexes, et cela augmente également les coûts de maintenance.
XMake réutilise comme base le langage bien connu Lua, et fournit une syntaxe de configuration plus simple et plus directe.
Lua est un langage simple et léger. Il n'y a que quelques mots-clés et types intégrés. Il suffit de lire un article pour pouvoir commencer. Par rapport à un DSL (NDT: Domain-specific language), vous pouvez obtenir beaucoup d'informations pertinentes plus facilement sur Internet.
Syntaxe de base
Cependant, certaines personnes me diront : ne faut-il pas encore apprendre Lua ?
En réalité, ce n'est même pas nécessaire. XMake adopte la méthode de séparation du champ de description et du champ de script, de sorte que dans 80% des cas, les utilisateurs débutants n'ont qu'à configurer le champ de description d'une manière plus simple et plus directe. Il n'est pas nécessaire pour eux d'écrire un script Lua compliqué :
target("test")
set_kind("binary")
add_files("src/*.c")
add_files("test/*.c", "example/**.cpp")
Si, en raison des parenthèses, il s'agit toujours d'un appel de fonction d'un langage de script, nous pouvons également l'écrire de cette manière (l'ajout des parenthèses dépend des préférences personnelles, mais je recommande personnellement de les mettre).
target "test"
set_kind "binary"
add_files "src/*.c"
add_files "test/*.c"
add_files "example/**.cpp"
Il suffit de connaître les fonctions courante de configuration, même si l'on ne connaît pas du tout Lua, on peut mettre en place un projet rapidement.
Nous pouvons comparer la configuration de CMake :
add_executable(test "")
file(GLOB SRC_FILES "src/*.c")
file(GLOB TEST_FILES "test/*.c")
file(GLOB_RECURSE EXAMPLE_FILES "example/*.cpp")
target_sources(test PRIVATE
${SRC_FILES}
${TEST_FILES}
${EXAMPLE_FILES}
)
Ce qui est moins intuitif et lisible, d'un seul coup d'œil.
Configuration des conditions
Si vous avez une connaissance de base de Lua, telle que les conditions de base, vous pouvez les intégrer facilement :
target("test")
set_kind("binary")
add_files("src/main.c")
if is_plat("macosx", "linux") then
add_defines("TEST1", "TEST2")
end
if is_plat("windows") and is_mode("release") then
add_cxflags("-Ox", "-fp:fast")
end
En parallèle, nous pouvons comparer avec la version CMake :
add_executable(test "")
if (APPLE OR LINUX)
target_compile_definitions(test PRIVATE TEST1 TEST2)
endif()
if (WIN32)
target_compile_options(test PRIVATE $<$<CONFIG:Release>:-Ox -fp:fast>)
endif()
target_sources(test PRIVATE
src/main.c
)
Scripts plus complexes
Si vous avez une connaissance de base de XMake et êtes un peu familier avec la syntaxe Lua et que vous souhaitez une configuration personnalisée plus flexible, XMake fournit également des outils de personnalisations plus complets, et vous pouvez écrire n'importe quel script complexe.
Par exemple, avant la compilation, pour faire un traitement en amont sur tous les fichiers sources, et après la compilation, exécuter des commandes gradle externes pour le packaging ultérieur, et même nous pouvons réécrire les règles de linking internes pour avoir un contrôle complet sur l'édition de lien.
Nous pouvons utiliser l'interface d'imports de modules et importer le module d'extension de l'éditeur de liens pour avoir un contrôle plus fin sur la façon dont l'édition de lien est réalisée.
target("test")
set_kind("binary")
add_files("src/*.c")
before_build_file(function (target, sourcefile)
io.replace(sourcefile, "#define HAVE_XXX 1", "#define HAVE_XXX 0")
end)
on_link(function (target)
import("core.tool.linker")
linker.link("binary", "cc", target:objectfiles(), target:targetfile(), {target = target})
end)
after_build(function (target)
if is_plat("android" then
os.cd("android/app")
os.exec("./gradlew app:assembleDebug")
end
end)
Si vous utilisez CMake, vous pouvez également implémenter ceci avec add_custom_command, mais il semble que vous ne puissiez qu'exécuter simplement quelques commandes par lots, et que vous ne puissiez pas faire toutes sortes de conditions complexes, de chargement de modules, de scripts de configuration personnalisés, et ainsi de suite.
Bien sûr, il est possible de faire la même chose avec CMake, mais certainement pas aussi simplement.
Si vous êtes familier avec CMake, vous pouvez également essayer de compléter la configuration suivante :
add_executable(test "")
file(GLOB SRC_FILES "src/*.c")
add_custom_command(TARGET test PRE_BUILD
- TODO
COMMAND echo hello
)
add_custom_command(TARGET test POST_BUILD
COMMAND cd android/app
COMMAND ./gradlew app:assembleDebug
)
- How can we override link stage?
target_sources(test PRIVATE
${SRC_FILES}
)
Gestion efficace des dépendances
Comme nous le savons tous, dans le développement de projets C ou C++, la chose la plus importante est l'intégration de diverses dépendances, parce qu'il n'y a pas de système de gestion de dépendances complet comme Rust et Cargo.
Par conséquent, à chaque fois que nous voulons utiliser une bibliothèque tierce, nous devons trouver et étudier la façon dont elle peut compiler sur plusieurs plateformes, et nous rencontrons souvent divers problèmes de compilation, ce qui retarde considérablement le développement et ne lui permet pas de se concentrer sur le projet actuel.
Puis enfin, nous avons fini de porter la dépendance pour la plateforme actuelle (NDT: par exemple Windows). Si vous passez à une autre plateforme (NDK: par exemple Linux), vous devez à nouveau vous pencher sur la dépendance pour la porter. Afin de résoudre ce problème, certains gestionnaires de dépendances tiers (tels que vcpkg/conan/conda, etc.) sont apparus, mais certains ne prennent pas en charge les versions sémantiques. Les plateformes supportées sont limitées, mais quoi qu'il en soit, il s'agit d'un grand pas vers la résolution de la gestion des dépendances de la bibliothèque C et en C++.
Cependant, avec seulement un gestionnaire de paquets, il est encore plus difficile de les utiliser dans les projets C et C++, car les outils de compilation correspondants doivent également être en mesure de les intégrer et de les prendre en charge correctement.
CMake et vcpkg
Regardons l'intégration de vcpkg dans CMake :
cmake_minimum_required(VERSION 3.0)
project(test)
find_package(unofficial-sqlite3 CONFIG REQUIRED)
add_executable(main main.cpp)
target_link_libraries(main PRIVATE unofficial::sqlite3::sqlite3)
Inconvénients:
- Une configuration supplémentaire est requise
-DCMAKE_TOOLCHAIN_FILE=/scripts/buildsystems/vcpkg.cmake - Ne supporte pas l'installation automatique des dépendances et nécessite que l'utilisateur exécute manuellement la commande
vcpkg install xxx.
(NDT: J'ai supprimé le dernier inconvénient concernant les versions sémantiques car elles semblent maintenant supportées)
CMake et Conan
cmake_minimum_required(VERSION 2.8.12)
project(Hello)
add_definitions("-std=c++11")
include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()
add_executable(hello hello.cpp)
target_link_libraries(hello gtest)
conanfile.txt :
[requires]
gtest/1.10.0
[generators]
cmake
Inconvénients:
- De façon similaire vous devez installer vous-même la dépendance avec
conan install ... - Vous devez créer un fichier conanfile.txt supplémentaire pour décrire les dépendances
Meson et vcpkg
Je n'ai pas trouvé comment utiliser vcpkg dans Meson, j'ai juste trouvé une discussion sur une issue.
Meson et Conan
Il semblerait que Meson ne supporte pas encore Conan, il y a une solution dans le document officiel pour l'utiliser mais elle est très compliquée. Je ne l'ai pas trouvée, vous pouvez chercher par vous-même : https://docs.conan.io/en/latest/reference/build_helpers/meson.html
XMake et vcpkg
J'en ai déjà parlé à maintes reprises. L'intégration d'autres outils de compilation et de gestion de paquets est très difficile à utiliser, et les différents gestionnaires de dépendances ont des méthodes d'intégration très différentes. Les utilisateurs veulent pouvoir changer rapidement entre Vcpkg et Conan, et la quantité de changement est très importante.
Maintenons, regardons comment vcpkg s'intègre dans XMake :
add_requires("vcpkg::zlib", {alias = "zlib"})
target("test")
set_kind("binary")
add_files("src/*.c")
add_packages("zlib")
Il suffit d'utiliser le nom de la dépendance correspondande dans la fonction add_requires et spécifier l'espace de nom vcpkg:: pour intégrer et utiliser directement le paquet zlib fourni par vcpkg.
Il suffit alors d'exécuter la commande xmake pour exécuter l'entièreté du processus de compilation, y compris l'installation automatique du paquetage zlib, sans avoir à exécuter manuellement vcpkg install zlib.
$ xmake
note: try installing these packages (pass -y to skip confirm)?
-> vcpkg::zlib
please input: y (y/n)
y
=> install vcpkg::zlib .. ok
[25%]: compiling.release src\main.cpp
[50%]: linking.release test
[100%]: build ok!
XMake et Conan
L'étape suivante est d'intégrer le package Conan et cela se fait exactement de la même façon, en replaçant juste le package manager cible.
add_requires("conan::zlib", {alias = "zlib"})
target("test")
set_kind("binary")
add_files("src/*.c")
add_packages("zlib")
XMake va également installer si nécessaire le package zlib dans Conan et puis automatiquement l'intégrer et compiler.
La gestion des dépendances intégrées à XMake
XMake et CMake sont des outils de compilation différents. La différence principale, et l'un des plus gros avantages, est que XMake dispose d'un gestionnaire de dépendance directement intégré. Nous pouvons nous passer complètement de vcpkg/conan et intégrer rapidement des dépendances, de cette façon :
add_requires("zlib 1.2.x", "tbox >= 1.6.0")
target("test")
set_kind("binary")
add_files("src/*.c")
add_packages("zlib", "tbox")
En outre, il prend également en charge la sélection sémantique complète des versions, l'intégration de dépendances multiplateformes, la compilation des dépendances avec une chaîne de compilation croisée (NDT: cross-compilation toolchain) et même l'extraction et l'utilisation automatiques des outils de compilation depuis des packages.
De plus, nous pouvons également compter sur des configurations de base pour mieux configurer nos dépendances :
Utiliser la version de debug d'un package
Nous pouvons utiliser la version de debug d'une bibliothèque pour pouvoir utiliser des points d'arrêts (NDT: breakpoints) et débugger directement dans nos dépendances.
add_requires("zlib", {debug = true})
Changer le runtime de Visual Studio
add_requires("zlib", {configs = {vs_runtime = "MD"}})
Utiliser la version dynamique
Par défaut xmake utilise la version statique des bibliothèques, nous pouvons néanmoins choisir leur version dynamique :
add_requires("zlib", {configs = {shared = true}})
Support de la version sémantique
Le gestionnaire de dépendance intégre à XMake supporte complètement les versions sémantiques :
add_requires("zlib 1.2.x")
add_requires("zlib >=1.2.10")
add_requires("zlib ~1.2.0")
Ne pas utiliser la version système
Par défaut, si les versions correspondent, XMake donnera la priorité à la recherche et à l'utilisation des bibliothèques dont l'utilisateur dispose déjà sur son système. Bien sûr, nous pouvons aussi interdire de force la recherche et l'utilisation des bibliothèques du système, et ne télécharger les dépendances qu'à partir du dépôt de paquets intégré.
add_requires("zlib", {system = false})
(NDT: il semblerait qu'une erreur se soit glissée dans l'article de base, la valeur était à true mais c'est false qui désactive ce comportement).
Dépendances optionnelles
Si l'intégration d'une dépendance échoue, XMake va automatiquement signaler une erreur et interrompre la compilation en indiquant à l'utilisateur : "zlib not found". Mais nous pouvons aussi l'indiquer comme une dépendance optionnelle.
De cette façon, même si la bibliothèque n'a pu être installée correctement, la compilation se poursuivra.
add_requires("zlib", {optional = true})
Configurations personnalisées
Par exemple, pour intégrer la bibliothèque Boost avec les modules context et coroutines, on peut écrire :
add_requires("boost", {configs = {context = true, coroutine = true}})
Le support d'autres gestionnaires des dépendances
En plus de supporter vcpkg/conan et son propre gestionnaire de dépendances, XMake supporte également d'autres sources de dépendances comme Conda/Homebrew/apt/Pacman/clib/Duc, etc. et la façon de les intégrer est exactement la même.
Les utilisateurs peuvent passer d'une source à une autre sans passer plus de temps à se demander comment les intégrer.
Voilà pourquoi XMake ne détruit pas l'écosystème autour du C et du C++ : il préfère réutiliser les outils existants et s'efforce d'améliorer l'expérience utilisateur autour de la gestion des dépendances en C/C++, améliorer la productivité et permettre aux développeurs de consacrer plus de temps sur le développement lui-même.
XMake supporte (avec exemple) :
- Sa propre source de dépendances, xmake-repo (tbox >1.6.1)
- Son propre gestionnaire de dépendances, xrepo.
- Des sources paramètres par l'utilisateur.
- Conan (conan::openssl/1.1.1g)
- Conda (conda::libpng 1.3.67)
- Vcpkg (vcpkg:ffmpeg)
- Homebrew/Linuxbrew (brew::pcre2/libpcre2-8)
- Pacman sur Archlinux/MSys2 (pacman::libcurl)
- Apt sur Ubuntu/Debian (apt::zlib1g-dev)
- Clib (clib::clibs/bytes@0.0.4)
- Dub (dub::log 0.4.3)
Commande de gestion des dépendances (xrepo)
Pour faciliter la gestion des dépendances dans le référentiel intégré à XMake, XMake dispose également de la commande xrepo.
Nous pouvons utiliser cet outil pour effectuer rapidement et facilement les opérations de gestion suivantes :
Installation d'un paquet : xrepo install zlib
Désinstallation d'un paquet : xrepo remove zlib
Obtenir des informations sur un paquet : xrepo info zlib
Obtenir les informations de compilation d'un paquet : xrepo fetch zlib
Charger l'environnement du paquet : xrepo env shell (c'est une fonctionnalité très puissante)
Vous pouvez consulter la page d'accueil du projet xrepo pour en savoir plus et avoir plus d'exemples d'utilisation.
Léger et sans dépendances
Pour utiliser Meson/Scons, vous devez d'abord installer python/pip. Pour utiliser Bazel, vous devez installer un environnement d'exécution tel que Java.
XMake n'a pas besoin d'installer d'autres bibliothèques et dépendances. Son propre paquet d'installation ne fait que 2 à 3mo, ce qui est très léger.
Bien que XMake soit basé sur Lua, grâce aux caractéristiques légères du langage Lua, xmake l'a entièrement intégré, de sorte que l'installation de XMake équivaut à avoir une VM Lua complète.
Certains diront qu'il faut toujours installer le compilateur pour compiler XMake mais ce n'est pas toujours nécessaire. Sous Windows, nous fournissons un installateur avec XMake précompilé, qui peut être téléchargé et installé directement.
L'adresse est la suivante : Releases.
De plus, XMake supporte également le téléchargement de la chaîne de compilation, donc même si votre système ne dispose d'aucun compilateur, cela n'a pas d'importance, les utilisateurs n'ont pas à se soucier de la façon de lancer l'environnement de compilation, ils ont seulement besoin de spécifier les outils nécessaires dans leur xmake.lua.
Par exemple, si nous utilisons la chaîne d'outils mingw-w64 pour compiler des projets C/C++ sur Windows, nous avons seulement besoin de la configuration suivante:
add_requires("mingw-w64")
target("test")
set_kind("binary")
add_files("src/*.c")
set_toolchains("mingw@mingw-w64")
Après avoir lié les outils de compilation par la configuration set_toolchains, XMake détectera automatiquement si MinGW-w64 existe sur le système actuel, et si ce n'est pas le cas, il téléchargera automatiquement le paquet mingw-w64 avant de procéder à la compilation, le tout en utilisant uniquement la commande xmake :
$ xmake
note: try installing these packages (pass -y to skip confirm)?
in xmake-repo:
-> mingw-w64 8.1.0 [vs_runtime:MT]
please input: y (y/n)
=> download https://jaist.dl.sourceforge.net/project/mingw-w64/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/8.1.0/threads-posix/seh/x86_64-8.1.0 -release-posix-seh-rt_v6-rev0.7z .. ok
checking for mingw directory ... C:\Users\ruki\AppData\Local\.xmake\packages\m\mingw-w64\8.1.0\aad6257977e0449595004d7441358fc5
[25%]: compiling.release src\main.cpp
[50%]: linking.release test.exe
[100%]: build ok!
En plus de MinGW-w64, XMake peut aussi installer d'autres toolchains, et même des toolchains de cross-compilation, comme llvm, llvm-mingw, tinycc, muslcc, gnu-rm, zig, etc.
Si vous souhaitez en apprendre plus sur l'intégration de toolchains distantes, vous pouvez lire l'article (NDT: en) Automatically pull the remote cross-compilation toolchain
.
Compilation parallélisée extrêmement rapide
Tout le monde sait que Ninja compile très rapidement, c'est pourquoi de nombreux développeurs aiment utiliser CMake/Meson pour générer un build.ninja, puis utiliser Ninja pour répondre aux besoins d'une compilation très rapide.
Bien que Ninja soit rapide, nous devons toujours générer le fichier build.ninja à partir des fichiers meson.build et CMakeLists.txt. Ce processus de génération prend plusieurs secondes voire dizaines de secondes.
XMake dispose non seulement de la même vitesse de compilation que Ninja, mais il n'a pas besoin de cette étape supplémentaire de génération d'un fichier en plus. Il dispose directement d'un outil de compilation intégré.
Dans tous les cas, seule la commande xmake est nécessaire pour compiler très rapidement.
Nous avons effectué des tests comparatifs :
De la compilation multiplateforme à la portée de n'importe qui
Une autre fonctionnalité de XMake est de supporter efficacement et facilement la compilation à destination de plusieurs plateformes, que vous compiliez sous Windows/Linux/macOS, pour iOS/Android, ou autre.
La configuration de la compilation est similaire donc les utilisateurs n'ont pas besoin d'étudier une nouvelle façon de compiler sur chaque plateforme.
Compiler nativement des programmes Windows/Linux/macOS
$ xmake
CMake
$ mkdir build
$ cd build
$ cmake --build ..
Compiler pour Android
$ xmake f -p android --ndk=~/android-ndk-r21e
$ xmake
CMake
$ mkdir build
$ cd build
$ cmake -DCMAKE_TOOLCHAIN_FILE=~/android-ndk-r21e/build/cmake/android.toolchain.cmake ..
$ make
Compiler pour iOS
$ xmake f -p iphoneos
$ xmake
CMake
$ mkdir build
$ cd build
$ wget https://raw.githubusercontent.com/leetal/ios-cmake/master/ios.toolchain.cmake
$ cmake -DCMAKE_TOOLCHAIN_FILE=`pwd`/ios.toolchain.cmake ..
$ make
Je n'ai pas pu trouver de façon pratique pour configurer et compiler le programme iOS. Je n'ai pu trouver qu'une chaine d'outils iOS tierces pour configurer et compiler.
Cross-compilation
En général, il suffit de définir le répertoire racine de la toolchain à utiliser pour la cross-compilation. XMake détectera automatiquement la structure de la toolchain et récupèrera le compilateur à utiliser pour la compilation sans plus de configuration nécessaire.
$ xmake f -p cross --sdk=~/aarch64-linux-musl-cross
$ xmake
CMake
Il faut écrire un fichier supplémentaire (cross-toolchain.cmake).
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR aarch64)
set(TOOL_CHAIN_DIR ~/aarch64-linux-musl)
set(TOOL_CHAIN_INCLUDE ${TOOL_CHAIN_DIR}/aarch64-linux-musl/include)
set(TOOL_CHAIN_LIB ${TOOL_CHAIN_DIR}/aarch64-linux-musl/lib)
set(CMAKE_C_COMPILER "aarch64-linux-gcc")
set(CMAKE_CXX_COMPILER "aarch64-linux-g++")
set(CMAKE_FIND_ROOT_PATH ${TOOL_CHAIN_DIR}/aarch64-linux-musl)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
include_directories(${TOOL_CHAIN_DIR}/aarch64-linux-musl/include)
set(CMAKE_INCLUDE_PATH ${TOOL_CHAIN_INCLUDE})
set(CMAKE_LIBRARY_PATH ${TOOL_CHAIN_LIB})
$ mkdir build
$ cd build
$ cmake -DCMAKE_TOOLCHAIN_FILE=../cross-toolchain.cmake ..
$ make
Conclusion
Si vous débutez en matière de développement C/C++, vous pouvez utiliser XMake pour vous initier rapidement à la compilation de vos projets.
Si vous souhaitez développer et maintenir un projet cross-platform en C/C++, vous pouvez également envisager d'utiliser XMake pour s'occuper de la compilation et gagner en efficacité en vous permettant de vous concentrer sur le code du projet lui-même et non pas comment intégrer des bibliothèques tierces.
Bienvenue dans le projet XMake.