Discussion :

[oneDudeArmy]

Bonjour à tous,

Ayant fait quelques petits programmes simples en c, compilés en ligne de commande avec mingw, je voulais me mettre à utiliser le compilateur et l'IDE natifs de windows afin de faire plus simplement des programmes fenêtrés (j'utilisais auparavant la SDL mais je voudrais avoir accès à plus de fonctionnalités que n'en expose l'API de la SDL et faire certaines choses moi-même en interagissant directement avec l'OS. C'est parti, j'installe donc visual studio 2022. Je pars d'un projet vide, je compose un programme minimal en m'aidant de msdn (winmain + windproc) et je teste : ça compile, youpi.

Hélas la joie aura été de courte durée car j'ai remarqué des bizarreries qui ont le don de m'agacer. J'ai essayé de faire quelques tests afin de comprendre ce qui se passait mais je pense que les habitués pourront m'apporter une aide précieuse dans cette quête.

1) Il semble que Visual Studio 2022 utilise en interne un système de contrôle de version (et ce _même_ si on désactive le contrôle de version dans les options). Car quand on ajoute des dossiers / fichiers manuellement dans le dossier du projet (pour ajouter les .h et .lib des bibliothèques qu'on veut utiliser, ils sont marqués d'une petite icône "moins" rouge dans l'explorateur de solution. En cliquant droit dessus on peut les ajouter ensuite manuellement au projet mais est-ce la méthode "correcte" pour ajouter des fichiers / dossiers de bibliothèques à un projet ? Il semble que copier-coller des dossiers / fichiers via l'explorateur (de windows) puis "valider" les fichiers via l'explorateur de solution soit la seule méthode à part recréer les dossiers "include" et "lib" etc de la bibiothèque téléchargée via l'explorateur de solution et importer un à un les fichiers contenus (!) -> Car l'explorateur de solution ne permet ni d'importer un dossier et son contenu ni plusieurs fichiers à la fois (!).

2) Question subsidiaire : si ce contrôle de version est bien intégré et non-désactivable, qu'est ce que ça change et comment doit-on faire "proprement" ces opérations ?

3) Une autre bizarrerie que j'ai remarqué : si mettons j'installe manuellement la SDL par exemple (que je compte utiliser uniquement pour l'affichage le temps d'apprendre une API de rendu). Donc je télécharge la version de dev pour visual studio de la SDL, je crée un dossier "dependencies" dans le dossier de mon projet via l'explorateur (de windows), puis un sous-dossier SDL2 et je copie colle les dossiers "include" et "lib" de la SDL dedans. J'actualise l'explorateur de solution de visual studio : mon dossier dependencies ajouté manuellement ainsi que son contenu apparaissent dans mon projet. Et c'est là que ça devient bizarre :

a) Si je n'ajoute aucun des fichiers ajoutés manuellement au projet, je dois ajouter les dossiers "include" et "lib" aux réglages du compilateur et de l'éditeur de lien, et je dois ajouter la liaison aux deux bibliothèques SDL2.lib et SDL2main.lib pour compiler (normal).

b) Mais si j'ajoute au projet les fichiers ajoutés manuellement au dossier du projet via l'explorateur de solution, alors je n'ai besoin d'ajouter aucun "dossier include" et aucun "dossier lib" dans les propriétés du projet, ni même d'ajouter la liaison aux deux bibliothèques SDL2.lib et SDL2main.lib. Cela compile, visual studio "trouve tout tout seul" (répertoires et .lib). Enfin il me semble bien. Est-ce qu'il scanne les fichiers pendant l'ajout au projet et le fait automatiquement en mode ninja ? Ce comportement "magique" que je ne comprends guère me laisse songeur. Parce que quand on sait pas comment un truc marche, on est pas sûr qu'il marche et dans quelle conditions il marche...

Tout éclaircissement serait le bienvenu Merci d'avoir pris le temps de me lire !

[umfred]

Sauf erreur de ma part ce n'est pas du versioning, mais (si je peux dire) de la configuration de projet.
Tu dis via l'explorateur quels sont les fichiers à prendre en compte pour le projet.
Le fait de définir un dossier lib et include permet d'avoir dans un autre dossier ces fichiers, sans qu'ils soient directement lié au projet (c'est un peu comme la différence entre un #include<...> (=ajout du chemin au réglage compilateur) et un #include "..." (=ajout via l'explorateur de solution))

[oneDudeArmy]

umfred: Merci de ta réponse à ma question 1) ! Mais du coup alors, qu'est-ce que tu penses de ma question / observation 3) ? C'est quand même bizarre non ? Une fois les .h et .lib de la SDL ajoutés au projet via l'explorateur de solution, pas besoin de modifiier les propriétés du projet pour ajouter les chemins des dossier "include" (compilateur) et "lib" (pour l'éditeur de liens) ni même d'ajouter les .lib (input de l'éditeur de liens). Par quelle magie et surtout qu'est ce que visual studio fait précisément pour que la compilation "fonctionne" sans lui donner ces infos ?

[umfred]

En 3-a, le compilateur va savoir où chercher les fichiers (avec le nom que tu leur spécifies pour la liaison). Si tu ne rajoutes pas les dossiers, il faudra spécifier le chemin complet, sauf erreur de ma part.
En 3-b, comme les fichiers font explicitement partis du projet, ils seront forcément lier à la compilation (donc pas besoin de les rajouter à la commande)

Pour le 1, il me semble que si les fichiers sont présent quelque part en dehors du fichier du projet, tu peux tout de même les rajouter via Ajouter > Element existant et en allant pointer vers les fichiers, (les fichiers seront rajoutés au projet mais pas déplacer dans le dossier du projet)

[oneDudeArmy]

umfred : Merci pour tes explications ! Du coup selon toi, quels types de fichiers sont à inclure dans un projet visual studio et pour quelles raisons ? Prenons l'exemple d'un programme de type jeu vidéo par exemple, qui utilise pas mal de petites librairies externes (.h et .lib) , qui a des fichiers de ressources (textures, shaders, musiques, sons, niveaux...). Sur quels critères se baser pour savoir si un fichier fait partie du projet visual studio ?

[umfred]

Je dirais (mais je suis sans doute le mieux placer pour donner des recommandations, vu que je ne développe pas en C++ sur VS) qu'à partir du moment où les librairies ne sont pas de toi, que tu ne vas pas les modifier (ou qu'il y a "beaucoup" de fichiers), je déclarerais pour cela un (ou plusieurs) dossier au niveau du compilateur. Si ce sont des ressources/librairies que tu écris et qui peuvent évoluer et surtout qui sont propres au projet, les ajouterais en tant que fichier du projet.
ça serait ma logique (qui n'est peut-être pas la bonne logique)