Pour activer l'affichage complet des commandes passées par le système de build (par exemple pour connaître les options passées à la compilation d'un fichier source), il suffit de suffixer la commande make avec SILENT=. Par exemple, depuis le répertoire src, lancer: make all SILENT= (le = n'est pas une faute de frappe, il permet d'effacer la valeur de la variable correspondante dans le makefile).
Une autre solution est de ne pas rester au niveau de la racine (${OSDL}/trunk) mais d'aller dans un sous-répertoire de ${OSDL}/trunk/src/code. En effet, il a été fait en sorte que, quand on choisit un niveau de détail supérieur (ex: celui du module ou du sous-module), les informations fournies soient plus détaillées.
La compilation des tests est séparée de celle de la bibliothèque en elle-même, car les tests sont faits pour se comporter exactement comme une application tierce qui utiliserait OSDL.
Cette dernière doit donc être complétement compileé (*.o), liée (*.a/*.so) et installée pour que les tests puissent être construits et s'exécuter. Ces tâches de construction conditionnelle et de résolution des tâches minimales sont prises en charge par le système de construction (build).
Pour exécuter les tests venant avec Ceylan ou avec OSDL, deux méthodes sont envisageables:
bin, les exécutables de tests sont automatiquement rangés dans une arborescence reflétant celle de leur module. Il est conseillé de les exécuter depuis leur répertoire de stockage (en plaçant le répertoire courant là où l'exécutable se situe), de manière à ce que, dans le cas où le test nécessite des ressources externes (ex: une image), il puisse d'emblée les trouver.
playTests.sh, qui se charge de les lister, de les enchaîner et de répertorier leurs éventuelles défaillances. Il est possible de l'exécuter en mode non-interactif (batch) via l'option --batch. Note: pour OSDL, cette option est utilisable, même si certains tests sont obligatoirement interactifs (dans ce cas ils rendent la main immédiatement).
Pour totalement contrôler les sous-systèmes d'OSDL (par exemple vidéo, audio, événements, etc.), il aurait été pratique de disposer de classes statiques comme en Java. Comme le C++ ne permet pas de garantir le moment ou l'ordre d'initialisation des classes contenant des membres statiques, il a été choisi, pour une meilleure construction du code, d'utiliser dans certains cas une méthode notamment exposée par Stephen Muires.
OSDL respecte un repère orthonormé classique : les coordonnées de l'écran s'étendent horizontalement (abscisses) de gauche à droite, du point de vue de l'utilisateur, et verticalement (ordonnées) de haut en bas. La base tridimensionnelle directe en découlant verrait donc le troisième axe, orthogonal aux deux autres, fuir l'utilisateur.
Pour toute remarque, envoyez-nous un mail !