Bonjour à tous.

Voila, depuis peu j'ai ré-organisé mon jeune moteur 3D en cours de developpement pour en faire une librairie statique.
Le projet s'appelle Moteur3D.

Maintenant, j'ai un autre projet, qui s'appelle Scene.
Et Scene utilise la librairie Moteur3D.

J'ai donc une solution avec ces deux projets là.
Mon but est de débugguer mon moteur facilement, avec ma petite scene d'exemple, qui a pour mission de tester les nouveautés du moteur.
Mon principal problème est la gestion de ces deux projets, lors de leur compilation respective.

1/ Input d'un projet = output de l'autre
-----------------------------------------
Pour l'instant, dès que je re-compile mon moteur, il faut que je récupère \Moteur&Scene\moteur3D\debug\moteur3D.lib que je viens de créer, et que je la copie dans
\Moteur&Scene\scene\
de manière à ce que ma scene utilise la dernière version compilée de mon moteur.
Et bien sur il faut que je la re-charge dans l'environnement de dev, de manière à ce que la lib chargée soit bien la dernière compilée

Je me demandais donc si il n'y avait pas moyen de faire en sorte que par défaut, mon projet scene prenne au niveau du linkeur comme input file la sortie de mon projet moteur3D.

Ainsi, quand je générerais la solution, moteur3D serait d'abord compilé, puis lors de la compilation de scene, le compilo récupèrerais immédiatement ce qui a été produit par moteur3D.

Voyez vous ce que je voudrais obtenir ?

2/ Header global du moteur destiné au projet Scene

--------------------------------------------------
---
Et j'ai le même probleme, ou presque, concernant l'interface de mon moteur : le header moteur3D.hpp, que j'inclu bien sur au projet scene.
Ce header contient l'ensemble des fonctions du moteur qui doivent être accessible depuis l'extérieur (depuis mon projet Scene donc).

Bon, le probleme c'est que bien sur mon moteur ne contient pas qu'un seul header.

Disons que j'ai : Moteur3D
il contient M1.h, M2.h, M1.cpp, M2.cpp
Des que je rajoute ou modifie des fonctions, bon je modifie la déclaration de mes fonctions au niveau de M1.h ou de M2.h.

le problème c'est qu'il faut aussi que je modifie l'en-tête Moteur3D.h qui servira pour le projet Scene.

Donc dès qu'il y a une modification, il faut que je pense à modifier les en-tete du moteur, et l'en-tete global qui me permet de me servir de mon moteur.

Comment pourrais-je rendre ce processus automatique ?

N'est-il pas possible d'utiliser, pour ce deuxieme probleme, un header pré-compilé ?
Je ne sais pas bien ce que c'est, et j'ai peut-etre une vision fausse de la chose, mais je voudrais que tous mes header du moteur soit "condensés", en un seul header; et mon projet Scene se servirait alors de ce header.

Et comme pour le 1/, je voudrais que ce header soit produit à chaque fois que je génère la solution.

Conclusion :
------------

En fait, voila par un petit diagramme ce que je voudrais obtenir :

Moteur3D
--------
->Composé des headers M1.h, M2.h
->Composé des sources M1.c, M2.c

->Produit Moteur3D.lib
->Produit une librairie "globale" qui "condense" M1.h et M2.h en un seul header (pré-compilé ?) C'est le header que j'appellais Moteur3D.h plus haut.

Scene
-----
-> composé du header S1.h
-> composé de la source S1.c
-> Utilise la dernière version compilée de Moteur3D.lib
-> Utilise la dernière version produite de Moteur3D.h

-> Produit Scene.exe

Voila, j'espere que vous comprendrais facilement ce que je voudrais obtenir.

Je ne sais pas si il y a des techniques qui permettent d'optimiser ces points-là, mais je pense (j'espere) qu'il existe des solutions.
En même temps pour générer de très grosses solutions, qui dépendent les unes des autres, je pense bien qu'il doit exister une solution.
je n'y connais pas grand chose, mais peut être que "LA" solution est pour le 1/ d'utiliser un makefile (je ne connais que le nom hein) et pour le 2/ d'utiliser un header pré-compilé.

Est-ce que je pars dans un bon axe de recherches ?
Je vous remercie pour l'aide que vous pourrez m'apporter.

NB : je ne suis pas un expert du processus de l'edition des liens, ni de l'utilisation de makefile, donc essayez de prendre ma "noobitude" dans vos réponses
Merci à tous.

Salut!

Je ne sais pas si tu est vraiment sur le bon site!
Tu devrais plutôt t'adresser un forum de developpez.com par exemple. D'autant qu'ils ont une section par langage ou type de projet (C++, C, Jeux, Web...)

Pour ma part je bosse surtout en C# où tout ça est simplifié... Mais je vais quand même te donner mon avis.

J'aurais personnellement tout mis dans le même projet et viré la scène d'essais une fois ton moteur terminé. Ou bien carrément intégré la scène en tant que composant de ton moteur 3D.

ça t'aurais simplifié la réponse pour les deux questions à la fois.

Mais si tu tiens à continuer sur ta lancée, essaie de voir dans les propriétés des projets :
dans ton projet moteur 3D, tu peux spécifier un répertoire de destination pour ta Dll.
Dans ton projet scène, spécifier l'entrée et donc le répertoire où est exportée ta dll à chaque compilation.

Dans Visual Pro 2005 (je ne sais pas si c'est le cas pour C++ express 2008), tu peux spécifier les dépendances des projets dans les propriétés de la solution. ça te permettra de générer le moteur avant la scène.

Mais je te conseille encore d'aller sur un site comme developpez.com

Si tu es étudiant, n'oublie pas que tu peux accéder aux versions pro de ces logiciels gratuitement.
Là : https://downloads.channel8.msdn.com/

merci pour ta réponse guitarnono.

Tout d'abord, je souhaiterais garder une solution composée de deux projets, pour la simple et bonne raison que je souhaite illustrer par cette scène "d'essai" l'utilisation future de mon moteur.
Je souhaite donc essayer de garder une vision séparée entre ma scène et mon moteur.

Par contre ton idée pour le répertoire de destination de ma lib n'est vraiment pas idiote :p
Je n'y avait même pas pensé en plus...
Je vais essayer de voir ça : répertoire d'exportation, et régler l'ordre de compilation des projets.

J'espere juste que apres chaque compilation, je n'aurais pas besoin de re-charger la librairie dans le projet scène.
Je vais voir ca.

Par contre des idées pour mon problème de header "global" au moteur, d'un moyen pour le générer automatiquement ?

je vais continuer à reflechir à tout ca, et accèpte volontier d'autre petites idées.
Je vous ferait part de ma reflexion.
J'avoue que c'est une des premières fois où je dois manipuler d'aussi grandes quantités de code, et que parfois ce n'est pas évident.
D'autant plus que je ne connais pas toutes les fonctionnalités de VC++ 2008.

Ha oui, et ton idée concernant la version pro grace à mon statut d'étudiant est très sympathique.
Je vais de ce pas voir le site, j'espère que ma fac participe au projet msdn.

Bonne soirée, et n'hésitez pas à réagir encore ...

En fait ton header Moteur3D.h doit simplement créer un accès à toutes les fonctions?
Alors il te suffit d'inclure M1.h et M2.h avec un #include"M1.h" dans moteur3D.h et c'est tout (et attention de bien laisser le reste du fichier vide pour ne pas créer de conflit entre les .h).
En cherchant une fonction, le compilateur va remonter tes .h jusqu'à trouver la bonne référence.

J'ai fait un petit essai simple chez moi et ça fonctionne (désolé pour le nom des fonctions...) :

"M1.h" :

1. include<stdio.h>

void pouet1();
void pouet2();

"M2.h" :

1. include<stdio.h>

void pouet3();
void pouet4();

"Moteur3D.h" :

1. include<stdio.h>
2. include"m1.h"
3. include"m2.h"

"Main.cpp" :

1. include<stdio.h>
2. include"moteur3D.h"

void main()
{
pouet1();
pouet2();
pouet3();
pouet4();
}

Pour plus de sureté, rajoute évidemment les #define, #ifndef et compagnie!

Si ta fac n'est pas représentée dans dreamspark, tu peux quand même envoyer une demande par la msdnaa ou mieux : acheter une carte ISIC (10€). Je te conseille quand même dreamspark, ça peut être intéressant pour programmer en XNA et développer des jeux à la fois sur PC et XBOX 360 (et les balancer sur la console évidemment).

Merci pour ton aide guitarnono

L'idée que tu as eu est intéressante et marcherais effectivement dans le cadre de ma scene de "test" (1 solution avec 2 projets : le moteur et la scene), mais à terme je veux fournir mon moteur en ne livrant que 2 fichiers : Moteur3D.hpp et Moteur3D.lib, avec Moteur 3D.hpp qui contient effectivement l'ensemble des fonctions et objets de mon moteur.
Avec ta méthode, je dois livrer en plus M1.h et M2.h

Mais peut être que je me trompe de voix.
En fait vous, quand vous créez une librairie statique, vous livrez les headers qui composent votre librairie sans "regrouper" les header dans un seul et meme en-tete, ou au contraire vous fournissez un seul .h regroupant l'ensemble ?

Je ne sais pas trop quelle est l'approche la meilleure.

Bon j'avoue que c'est vraiment du chipotage hein, mais je ne sais pas comment on est "sensé" le faire, si du moins une "norme" existe.

Donc en fait, place à vos petite expériences perso.

NB concernant la licence etudiant : oui, j'ai vu que ma fac n'y étais pas mais j'ai rempli le formulaire pour qu'ils me communiquent sous 3 semaines un identifiant pour le telechargement.
Au fait, je fais quoi moi apres, vaut mieux que je garde Visual Express 2008 en plus de la version commerciale 2008, ou je ne garde que la commerciale ?
(Ou eventuellement je ne garde que la version express ?)
Tiens à propos, est-ce que la version complete 2008 pour étudiant contient un marquage particulier ua niveau des exe générés qui permettent d'affirmer qu'ils on été créés avec la version étudiant ?

Bonne nuit à tous

Pour un gros projet, ce n'est certainement pas conseillé de tout regrouper dans un seul header. Ce veut dire qu'à chaque include, tout inclus l'ensemble de ta librairie.

J'aurais plutôt tendance à regrouper les classes par thème. En gros, faire un .h pour la manipulation des maillages, un autre pour la gestion des shaders, un autre pour la gestion du device graphique...
ça évitera au final, par exemple, d'inclure les shaders dans le code de ta scène qui gère les contrôles clavier, par exemple, et ça accélérera la compilation, puisque tu n'inclura que les portions dont tu auras besoin.

Enfin bref, pour un truc vraiment structuré, je pense qu'il faut éviter le "tout-en-un".

Pour les visuals, je suis resté à la version 2005, puisque mon vieux PC rame un peu avec la 2008, mais en principe, les projets en version express et pro sont plus en moins compatibles. La version pro offre pas mal de trucs en plus comme la structuration du projets en dossier, et globalement une meilleure gestion des solutions à plusieurs projets.
Après il n'y a rien qui différencie la version etudiant de la version commerciale : ils te filent un code d'activation de la même façon.
Et de toutes façons c'est pas le genre de microsoft de mettre des batons dans les roues des jeunes développeurs : ils ne veulent que les voir travailler sur leurs logiciels!

qq petits elements de reponse supplementaires:

- pour le regroupage des headers, regarder les tests de performance des compilateurs/linkers lors d'utilisation de SCU (single compilation unit). Les SCU peuvent rendre quasiment instantane la compilation de petits modules, comme des libs de maths, de physiques, etc. L'essentiels est de ne pas les abuser

- le decoupage en libs, statiques et/ou dynamiques, peut sembler contraignant, mais force des escalations/demotions qui reduisent le couplage. Pour les gros projets ou les projets sans "software architect" talentueux, c'est un bon moyen de forcer une certaine forme de structure. Bouquin ultime a lire: Large Scale C++ Software Design, de John Lakos

- pour les differentes versions de VisualStudio, les compilateurs sont identiques. Les IDE peuvent etre *legerement* differents (ie. pas de MFC design sous VC++ Express). La version pro rajoute des fonctions avancees: remote debugging, ClearCase reports, etc. qui ne devraient pas trop te faire defaut en tant que developpeur "autonome"