Équivalent de maven ou gradle en C++ ?

Bonjour,

Existe-t-il un équivalent de maven ou de gradle, mais pour le C++ ?

Lors de mes recherches, je retombe souvent sur CMake, mais ce n’est pas ce que je cherche, du moins il ne me semble pas. Je trouve CMake compliqué: il vérifie un tas de trucs, met 3 ans à s’exécuter, crée 12000 fichiers temporaires, et tout ça pour générer un fichier makefile qu’il faut encore exécuter avec les outils traditionnels derrière. ET en fait, il ne va rien télécharger et rien configurer du tout, donc ça ne simplifie pas vraiment le bordel. Le projet demande OpenSSL et tu ne l’as pas ? Tant pis, tu reviendras quand tu l’auras.

Ce que je cherche, ce serait un truc dans la lignée de gradle ou maven dans leur aspect gestion de dépendance.

Par exemple, j’indique dans un équivalent de build.gradle ou pom.xml que mon projet a besoin de WXWidgets, de CURL et d’OpenSSL.
J’ai pas OpenSSL ? L’outil télécharge ce qu’il faut, me le compile s’il n’existe pas de DLL précompilées existantes, me met automatiquement les includes et les lib d’import aux bons endroits, puis passe à la suite.
Finalement une fois que toutes les dépendances sont là, il compile mon projet.

Après pour l’aspect étapes de construction, je ne sais pas si c’est vraiment comparable, je n’ai jamais fait de test unitaire en C++, et il n’y a pas de déploiement sur un serveur. Par contre on a le build release et le build debug et les deux sont indépendants…

Je me doute bien que c’est bien plus compliqué qu’en Java, parce qu’il faut exactement la même version du même compilateur sur le même OS pour être sûr de pouvoir réutiliser des DLL, mais il n’y a pas non plus 36 combinaisons différentes il me semble (tout au plus une petite dizaine de très courantes ?) Donc ça doit forcément exister. Je n’utilise peut-être juste pas les bons mots dans mes recherches.

Actuellement je suis sur windows 10 avec MinGW-W64. Je ne tiens pas à passer à l’usine à gaz Visual Studio. Par contre un outil tel que je le décris m’inciterais peut-être à tenter un portage Mac ou Linux de mon logiciel, en théorie c’est possible car toutes les bibliothèques que j’utilise y sont disponibles.

Est-ce que vous connaissez quelque chose ?

Merci pour vos réponses.

Tu as plusieurs package manager, mais aucun n’est "officiel" en C++. Tu peux regarder xmake, conan, vcpkg, https://en.cppreference.com/w/cpp/links/libs#Package_managers etc.

Tout cet aspect package etc… manque cruellement au C++, on voit plusieurs initiatives que propose gbdivers mais aucun ne fédère et par conséquent, c’est toujours un peu délicat. À ces solutions j’ajoute que si on a l’impression que le dev est facilité sur Linux, je trouve que c’est en grande partie parce que justement on gère l’installation des libs au travers le package manager system.
CMake est largement plébiscité pour la configuration des projets, il serait dommage de s’en passer. Même si je trouve que xmake est une bonne idée, je ne l’utilise que sur des petits projets sandbox.

J’espère que tout cet écosystème va bien s’améliorer avec l’arrivée des modules dans C++ mais c’est pas pour tout de suite, le temps que ce soit au point et que les projets migrent doucement

Je voulais ajouter aussi pour la question des includes automatiques, c’est pas trivial, en particulier à cause des templates, il n’existe pas d’outil comme celui auquel tu penses je crois, en revanche j’ai pu mettre en oeuvre IWYU qui se débrouille pas si mal ! Faut garder en tête que c’est plutôt expérimental quand même, je l’ai pas mis en correction automatique du coup, il est resté en manuel, puisque j’ai pas entièrement confiance, mais jusqu’à présent il a été plutôt pertinent. Et c’est pas le même workflow que ce que tu as en java, tu le run pas sur un fichier pour qu’il t’inclu ce qui va bien, il faut écrire les fichiers un maximum correctement avec les includes, et le run à la compil sur l’ensemble, à ce moment il peut t’en suggérer s’il estime qu’il en manque et d’indiquer ceux qui sont inutiles.

Bonjour,

Merci pour vos réponses ! Conan et Xmake n’ont pas l’air si mal, mais effectivement là où le bas blesse surtout, c’est qu’on n’est pas certain de tout trouver, et qu’aucun n’a l’air de faire vraiment l’unanimité à l’instar de maven central.

JE vais voir s’il y en a un de ceux cités qui inclut toutes les bibliothèques dont j’ai besoin, mais ça reste profondément illogique. Ca fait un peu comme si toute la musique électro était exclusivement chez spotify, la pop uniquement chez deezer, et le rock chez apple… si tu aimes les trois genres, tu dois payer chez les trois, et te trimballer les trois applis incompatibles.

Je voulais ajouter aussi pour la question des includes automatiques, c’est pas trivial, en particulier à cause des templates, il n’existe pas d’outil comme celui auquel tu penses je crois

JE ne parle pas d’un outil qui va automatiquement ajouter les #include qui manquent dans ses propres fichiers. C’est jamais trop un gros problème ça, en général on trouve assez vite ce qui manque. Non, je parlais bien du package manager qui irait aussi télécharger les .h, .hpp, .a, .lib voire .dll/.so et qui spécifierait automatiquement au compilateur où ils sont pendant la phase de compilation (p.ex. pour GCC, avec -I et -L)

Par contre pour ça, j’imagine que ça doit être un peu le serpent qui se mord la queue… est-ce que c’est maven qui a imposé sa structure de répertoires src/{main|test}/{langage} ou est-ce que c’est une convention qui existait avant et que maven n’a fait que reprendre ? Parce qu’en C++ je n’ai pas l’impression qu’il y a de vraie convention pour ça et que du coup tout le monde fait un peu différemment, donc ça doit passablement compliquer la chose pour un package manager. En même temps de son côté, à tort ou à raison, C++ n’impose absolument rien au niveau de la structure des fichiers.

Tiens d’ailleurs, question stupide, pourquoi boost ont fait leur propre truc bien à eux et qu’il n’y a qu’eux qui l’utilisent ?

pourquoi boost ont fait leur propre truc bien à eux et qu’il n’y a qu’eux qui l’utilisent ?

Quel truc ?

une fois que toutes les dépendances sont là, il compile mon projet.

Tu peux faire ça avec CMake et surement les autres aussi, ou avec des submodules.

MinGW-W64. Je ne tiens pas à passer à l’usine à gaz Visual Studio.

VS n’a rien à avoir avec MinGW

Je pense qu’il faudrait que tu apprennes à utiliser les outils qui existent et si une lib n’est pas gérée, il faut que tu apprennes à compiler toi même et à l’intégrer dans ton système de build. Il n’y a pas d’équivalent propre/standard à ce que tu cherches en C++.

Mais tu peux avoir un équivalent simple de plusieurs façons, par exemple tu clones en recursive ton projet, puis tu le build, ça fait juste 2 lignes de commandes.

Je pense qu’il parle de Boost.Build (avec ses Jamfiles et sa commande 'b2’)
Je suppose qu’ils ont lancé ça parce que justement il n’y a pas de système de build standard, et qu’à une époque CMake était beaucoup moins populaire que maintenant (on peut voir encore beaucoup de projet qui sont gérés officielement par autotools mais c’esst pas trop cross-plateform parce que ça fait intervenir bash) Puis ils l’ont gardé parce que ça marche, ça répond à leur besoin, ça peut encore évoluer, mais je pense surtout que c’est parce que c’est inclus dans leur livraison, par conséquent l’utilisteur n’a pas besoin d’aller chercher un outil tiers, tout est déjà à disposition dans le livrable.

C’est vrai mais je crois que pour obtenir msvc (le compilateur uniquement) il n’y a pas le choix que de télécharger Visual Studio et ses composant pour C++, donc je comprend la position de QuentinC. Cependant je trouve que visual studio est plutôt bien géré maintenant avec le visual studio installer, et l’espace disque n’est pas très cher j’en ai souvent à revendre. Même s’ils ne sont pas très KISS, les concessions que ça demande ne sont pas excessives. En plus ces services supplémentaire sont plutôt de bonne qualité (IDE, Debug, documentation etc…)

Bof, c’est si le projet est bien fait, et tu dois aussi gérer ses dépendances et l’intégrer à ton system de build (ça tu l’as dit) qui peut être différent de l’officiel du projet.
ça se fait, bien sûr, mais c’est compliqué pour rien en C++ alors que tout plein de langages modernes résolvent ça au travers un package manager.

Pas d’accord avec cette métaphore, tous essaient d’avoir le répertoire le plus complet possible. C’est plus comme si tu montais une webradio et que tu ne savais pas quel source payer parce que tu ne sais pas si tu trouveras tout ce qui convient à tes auditeurs.

Ok désolé j’ai mal compris
C’est souvent pas un problème avec de grosses conséquences, mais la gestion des includes par les compilateurs fait que c’est assez facile d’include des choses que tu n’utilise plus avec l’évolution du code, ou d’utiliser des choses qui sont include au travers un autre include. Je le vois assez régulièrement dans de gros projets.

En effet, ça ça relève plus des bonnes pratiques ou des coding rules et ensuite tout est décrit dans le fichier de configuration de projet comme le CMakeLists.txt

pourquoi boost ont fait leur propre truc bien à eux et qu’il n’y a qu’eux qui l’utilisent ?

Quel truc ?

Leur système qui permet de compiler les parties de boost qui nécéssitent une compilation. Ils n’utilisent pas make, cmake, mais leur propre truc bien à eux.

Bon, il a le mérite de fonctionner du premier coup quand on lit attentivement les instructions et sans avoir besoin de se prendre la tête, au moins

VS n’a rien à avoir avec MinGW

JE sais bien. Par là je voulais dire que j’aimerais rester sur MinGW-W64 ou alors éventuellement passer à un autre compilateur en ligne de commande si c’était plus simple, mais ne pas être obligé de passer à VisualStudio, car je n’ai pas envie de me trimballer leur IDE gargentuesque dont je ne pourrais à peine me servir du 5% et encore. J’aime bien utiliser la ligne de commande + un éditeur léger genre Notepad++. C’est pas pour un projet d’entreprise où quelque chose est imposé.

Je pense qu’il faudrait que tu apprennes à utiliser les outils qui existent et si une lib n’est pas gérée, il faut que tu apprennes à compiler toi même et à l’intégrer dans ton système de build. Il n’y a pas d’équivalent propre/standard à ce que tu cherches en C++.

Touché… c’est peut-être là mon vrai problème en fait.

Par exemple, je n’arrive pas à comprendre comment ils font pour compiler des bibliothèques sous windows proprement quand ils ne fournissent que des scripts bash configure, quand bien même ils disent dans leur doc que c’est multiplateforme. J’ai pas envie de compiler une bibliothèque pour windows depuis linux ! Je ne sais pas comment ça marche et de toute façon c’est complètement ridicule.

Je ne comprends pas non plus comment on peut compiler une bibliothèque dite multiplateforme pour windows quand dans les premières lignes on voit un #include<unistd.h> ou #include<uninet.h>qui n’est pas éliminé par des quelconques #ifndef/#ifndef/#endif

Alors des fois j’ai de la chance, g++ *.cpp et ça marche, des fois j’en ai un peu moins et après avoir supprimé ou légèrement modifié manuellement quelques fichiers ça passe, mais souvent je jette l’éponge.

Bref, à chaque fois je galère et ça m’énerve. ET effectivement, c’est peut-être bien là mon problème. J’ai pas la bonne technique.

il n’y a pas le choix que de télécharger Visual Studio

Tu peux récupérer les build tools, tu n’as pas besoin de VS pour msvc

mais c’est compliqué pour rien en C++

Ben on a pas trop le choix vu qu’il n’y a rien de centralisé

un autre compilateur en ligne de commande

C’est ton système de build que tu vas utiliser en ligne de commande, pas le compilateur, enfin j’espère

Bref, à chaque fois je galère et ça m’énerve.

C’est normal

Quand les libs sont bien faites, tu lis la doc, tu tapes les 3 commandes qu’ils te filent et c’est bon. Pour les autres .. ben c’est galère, il faut corriger leurs erreurs et se débrouiller. Tu devrais demander directement de l’aide pour ces libs en question, soit tu n’as pas compris les infos pour build, soit les libs sont juste foireuses.

C’est ton système de build que tu vas utiliser en ligne de commande, pas le compilateur, enfin j’espère

Mouais, exact, mais bon, on joue sur les mots là.

ET système de build, ben j’ai juste mingw32-make fourni avec MinGW, c’est pas un truc automagique hein.

J’ai pas vraiment compris ce que pouvait m’apporter CMake vu qu’il ne fait que générer un makefile, il ne fait apparament rien de plus magique que make.

En plus il est très con, CMake. Pour pouvoir générer un makefile MinGW, il me demande de supprimer sh du path. Du coup je renomme sh en sh2, mais derrière pour que le makefile marche, sh est nécessaire !

Bref, à chaque fois je galère et ça m’énerve.

C’est normal

Eh bien bravo

Quand les libs sont bien faites, tu lis la doc, tu tapes les 3 commandes qu’ils te filent et c’est bon.

Oui, les instructions de la doc, ça ça a marché nickel chez moi pour WXWidgets, lua, SQLite et boost.

Pour les autres .. ben c’est galère, il faut corriger leurs erreurs et se débrouiller. Tu devrais demander directement de l’aide pour ces libs en question, soit tu n’as pas compris les infos pour build, soit les libs sont juste foireuses.

Je ne pense pas que les libs en question soient foireuses. C’est moi qui doit être nul, c’est pas possible autrement. Les libs en question sur lesquelles j’ai déjà galéré: CURL, libzip, OpenSSL et LibreTLS, entres autres. C’est pas comme si c’était des bibliothèques utilisés par seulement trois projets d’amateur, non plus.

OpenSSL c’est juste incompréhensible (bon c’est connu pour être cryptique), j’ai voulu tenter LibreTLS et c’est presque pire. CURL ce qui pose problème c’est le support de SSL aussi, s’il n’y en avait pas besoin ça irait (mais sans support de HTTPS, CURL ne sert à peu près à rien pour ce que je prévoyais de l’utiliser). Et libzip j’ai fini par y arriver en modifiant moi-même deux ou trois trucs à la mano et sans passer par leurs scripts, mais pour une lib qui est officiellement utilisée par PHP (et Python sauf erreur) c’est quand même assez moyen de devoir le faire. Je ne suis quand même pas le seul con réfractaire au clicodrome VisualStudio au monde non ?

Leur système qui permet de compiler les parties de boost qui nécéssitent une compilation. Ils n’utilisent pas make, cmake, mais leur propre truc bien à eux.

Il y avait des discussions pour remplacer b2/bjam par un système de build plus commun… C’est à dire CMake. Mais visiblement ce n’est pas (encore?) fait. Si on prend les versions autonomes des libs de boost, il y a un Jamroot et un CMakeLists.txt.

Je ne comprends pas non plus comment on peut compiler une bibliothèque dite multiplateforme pour windows quand dans les premières lignes on voit un #include<unistd.h> ou #include<uninet.h>qui n’est pas éliminé par des quelconques #ifndef/#ifndef/#endif

Probablement parce que selon les plateformes tous les fichiers ne sont pas utilisés ou sont inclus à travers d’autres fichiers qui utilisent #ifndef et compagnie.

J’ai pas vraiment compris ce que pouvait m’apporter CMake vu qu’il ne fait que générer un makefile, il ne fait apparament rien de plus magique que make.

CMake est un générateur de fichier de dépendance. Il génère un fichier qui permet d’être utilisé par des programmes dédiés tel que Make, Ninja, VS, etc (j’en ai 14 sur mon linux).

Même si je trouve le langage de CMake particulièrement immonde, c’est beaucoup plus simple de passer par lui pour propager les options des libs que de le faire directement dans un Makefile. Il peut aussi s’interfacer avec certains gestionnaires de paquet cité par gbdiver: conan, vcpkg, cpm. xmake/xrepo font de même.

Je trouve étrange ton histoire de sh/sh2, mais c’est peut-être qu’il s’attend à trouver bash. Utiliser un autre générateur peut potentiellement corriger le problème. Personnellement, je trouve que Ninja permet de compiler plus rapidement que Make et crée moins de fichier intermédiaire (il y a toute une magouille ajoutée par cmake avec les Makefile pour avoir un pourcentage d’avancement), mais il y a une option à ajouter pour avoir de la couleur sur les erreurs de compilations puisque CMake les fait sauter :/. On peut configurer la variable d’environnement CMAKE_GENERATOR ou utiliser l’option -G pour changer le générateur.

Je ne pense pas que les libs en question soient foireuses. C’est moi qui doit être nul, c’est pas possible autrement. Les libs en question sur lesquelles j’ai déjà galéré: CURL, libzip, OpenSSL et LibreTLS, entres autres. C’est pas comme si c’était des bibliothèques utilisés par seulement trois projets d’amateur, non plus.

C’est le genre de lib qui demande pas mal d’option pour être compilé convenablement et qui ont eux-mêmes des dépendances sur des libs qui doivent être préalablement installées. C’est assez facile de rater une info si on lit un peu trop vite les fichiers INSTALL.md. Je ne serais pas étonné non plus qu’une partie des fichiers d’OpenSSL soit généré au moment de la compilation et qu’il y ait des fichiers asm qui traîne, un simple gcc **.c n’est pas suffisant. D’ailleurs, je ne sais plus si c’était pour openssl ou ffmpeg, mais au boulot on avait des erreurs sur les options de compilation concernant -fPIE/-fPIC et on a mis un bout de temps à trouver l’option dédiée.

Je trouve étrange ton histoire de sh/sh2, mais c’est peut-être qu’il s’attend à trouver bash. Utiliser un autre générateur peut potentiellement corriger le problème.

Je change déjà explicitement et systématiquement le générateur de CMake avec l’option -G pour "MinGW Makefiles". IL y en a un autre que je peux utiliser ? parce que sinon par défaut si je ne spécifie rien il essaye uniquement MSVC et je ne l’ai pas installé. Je suppose qu’il n’est pas capable de détecter MinGW tout seul (est-ce qu’il essaye de détecter quoi que ce soit en fait ? je n’ai pas l’impression).

Ce qui est le plus bizarre c’est que dans la phase de génération, CMake me dit clairement qu’il ne veut pas de sh dans le path. Il refuse de générer un makefile s’il trouve un sh quelque part. In fait vraiment un test spécifique pour ça. Pourquoi ? Aucune idée. Mais par contre pour la phase suivante, sil n’y a pas de sh, c’est mingw32-make qui ne marche pas.

J’ai peut-être un autre problème. Dans mes makefile perso (donc sans CMake), j’utilise la commande mkdir -p pour créer une hiérarchie de répertoires automatiquement et surtout ne pas provoquer d’erreur s’ils existent déjà. La commande mkdir standard de windows ne supporte pas cette option, mais j’ai un mkdir.exe inclus avec git.

La bizarrerie c’est que sur un de mes PC, mkdir -p fonctionne tel quel, alors que sur un autre, ça ne fonctionne pas, je dois changer pour mkdir.exe -p pour que ça fonctionne. Je ne comprends pas ce qu’il y a de différent entre les deux PC, les deux ont windows 10, le même git et le même MinGW d’installé.

Pour ce qui est des couleurs et du pourcentage d’avancement, je m’en fiche complètement. Du coup je vais aller aussi voir ce que c’est ninja, ne ne connais pas.

Merci.

Par exemple, j’indique dans un équivalent de build.gradle ou pom.xml que mon projet a besoin de WXWidgets, de CURL et d’OpenSSL.
J’ai pas OpenSSL ? L’outil télécharge ce qu’il faut, me le compile s’il n’existe pas de DLL précompilées existantes, me met automatiquement les includes et les lib d’import aux bons endroits, puis passe à la suite.
Finalement une fois que toutes les dépendances sont là, il compile mon projet.

Après pour l’aspect étapes de construction, je ne sais pas si c’est vraiment comparable, je n’ai jamais fait de test unitaire en C++, et il n’y a pas de déploiement sur un serveur. Par contre on a le build release et le build debug et les deux sont indépendants…

Je me doute bien que c’est bien plus compliqué qu’en Java, parce qu’il faut exactement la même version du même compilateur sur le même OS pour être sûr de pouvoir réutiliser des DLL, mais il n’y a pas non plus 36 combinaisons différentes il me semble (tout au plus une petite dizaine de très courantes ?) Donc ça doit forcément exister. Je n’utilise peut-être juste pas les bons mots dans mes recherches.

conan fait très exactement ce que tu demandes. Leur repo public dispose des binaires pré-compilés pour une grande variété de combinaisons. Chaque combinaison est identifiée par un hash en fonction de l’OS, l’architecture, le compilateur et sa version, le standard C++ demandé, la "variante" de lib standard utilisée (MT ou MD pour msvc par exemple), type de build (Release, Debug etc), static ou shared, PIC ou pas (pour les OS Unix si static), les options spécifiques de la lib, les versions majeurs des dépendances, etc. Inutile de te dire que le nombre de combinaisons différentes peut être énorme (36… hihi tu es loin de la réalité). Si tu demandes une combinaison dont le binaire n’existe pas sur le repo, ça build chez toi en local sous peu que tu aies demandé ce comportement, sinon il télécharge le binaire.

vcpkg c’est un peu pareil, mais sans les binaires pré générés, on ne fait que du build from source en local. Il a aussi longtemps été très pénible de demander des versions spécifiques des librairies, mais il ont ajoutés un truc (tordu je trouve), je ne sais pas si c’est aussi puissant que conan à ce niveau là. Comme je connais moins, et que ça évolue pas mal, ce que je dis n’est peut être plus à jour.

vcpkg a actuellement un peu plus de librairies que conan, mais tous les 2 sont encore jeunes vis à vis des gestionnaires systèmes bien connus. En tout cas ils ont quasiment toutes les libs mainstream. Il n’y a pas encore de gagnant parmi ces 2 gestionnaires, l’écosystème du C et C++ est complètement fragmenté à tous les niveaux, et il y a encore plein de gens qui n’utilisent pas du tout de gestionnaire de paquet.

Par exemple, je n’arrive pas à comprendre comment ils font pour compiler des bibliothèques sous windows proprement quand ils ne fournissent que des scripts bash configure, quand bien même ils disent dans leur doc que c’est multiplateforme. J’ai pas envie de compiler une bibliothèque pour windows depuis linux ! Je ne sais pas comment ça marche et de toute façon c’est complètement ridicule.

S’il y a un script shell à lancer, le mieux c’est de le faire dans MSYS2. Mais effectivement les autotools et les fichiers qu’ils génèrent n’ont jamais vraiment été pensés pour Windows. Réussir à compiler une librairie avec Visual Studio lorsque tu n’as que des fichiers autotools est en général une épreuve du combattant. Avec MinGW ça fonctionne mieux en général, mais on a toujours des surprises.

Pour ce qui est des couleurs et du pourcentage d’avancement, je m’en fiche complètement. Du coup je vais aller aussi voir ce que c’est ninja, ne ne connais pas.

Ninja affiche aussi un avancement, mais sous forme de nombre de taches traitées, je préfère. Et effectivement Ninja c’est top. C’est aussi la force de CMake vs autotools, les autotools sont maqués avec les Makefile, pas CMake.

T’as plein de façon différentes pour faire ce que tu veux avec l’écosystème actuel, mais non il n’y a pas une façon standard de le faire en C++. C’est à la fois une force et une faiblesse du langage ; une force car n’importe qui peut s’en sortir avec les sources et résoudre les dépendances de la façon qu’il souhaite pour ses besoins qui peuvent être ultra-spécifique (je pense à l’embarqué et à l’interfaçage avec d’autres langages) ; une faiblesse car plusieurs solutions pour résoudre le même problème existe et aucune n’est standard ce qui résulte forcément en un écosystème illustré par le célèbre xkcd:

Pour te donner une perspective : une autre solution que tu peux envisager est d’installer un terminal ubuntu via WSL sous ton windows. Tu installes ensuite via apt tes compilateurs/dépendances et build dans la console avec Make. Tu peux exécuter ton code dans ta console et exporter l’affichage en installant un serveur X dans ton WSL et Xming sous windows si t’as un GUI… Tu peux utiliser un éditeur type VS Code qui te permet d’utiliser tout type de terminal dans son onglet intégré : powershell, git bash, ton wsl, etc. Tu peux cross compiler depuis ton wsl pour exécuter ensuite sous windows et vice versa. L’avantage est que tu reste sous windows et utilise tes compétences actuelles (Makefile ?) pour avoir un projet que tu peux exécuter rapidement sans avoir à apprendre, par exemple, cmake.

Quelques infos supplémentaires :

• tu peux gérer tes dépendances en dur via git submodule (mais c’est lourd)
• tu peux gérer tes dépendances via CMake avec Fetch_external
• il existe des meta-package manager comme pmm, cpm qui vont essayer de charger conan, vcpkg ou un fetch_external "under the hood" pour linéariser un peu le process.
• tu peux utiliser conan sous linux et windows pour compiler/cross-compiler vers/depuis linux/windows
• tu peux utiliser vcpkg pour faire la même chose (il existe des community triplets, pour mingw par exemple)
• on parle de docker ? meson ? build2 ? Bazel ? Gn ?
• procure toi un IDE de base qui gère cmake pour toi. VS Code gère très bien cmake avec son plugin. VS te permet aussi d’ouvrir un projet cmake sans avoir un fichier solution.

Je sais que cela parait un peu overkill mais il y a tellement de possibilités avec l’écosystème actuel que ca ne sert à rien d’essayer de tout maîtriser ou de chercher 150 ans pour trouver un éventuel patchwork de solutions bancales qui ne répondent qu’à un seul besoin spécifique. C’est contre productif. Essaye plutôt de te familiariser avec les outils qui sont de-facto standard de nos jours: cmake, conan et vcpkg sont un bon début. Sous windows conan + vcpkg marchent très bien et offre une intégration vraiment seamless. Conan ne te sera utile dans un premier temps que si tu veux packager ta bibliothèque pour la publier. si ce n’est pas un problème que tu cherches à résoudre, alors je te conseille de le mettre de côté pour le moment .