Répertoire include externe

[Harooold]

Bonjour,

J'ai un peu de mal à arriver à avoir les #include qu'il faut dans les fichiers .cpp generés.
Mon projet a une hierarchie de fichiers semblable à :

MyProject
- trunk

-- include
--- package1
---- MyClass.h
--- package2

-- src
--- package1
---- MyClass.cpp
--- package2

Aucun problème pour dire à bouml de generée les .cpp et .h dans leurs repertoires respectifs mais le #include generé dans les .cpp me pose un peu plus problème..

Dans mon IDE favori j'ai défini le repertoire MyProject/trunl/include comme un repertoire d'include et donc je peux par exemple dans MyClass.cpp faire un simple #include <package1/MyClass.h>

J'essaie de configurer bouml pour qu'il me genère le même genre d'include. Actuellement j'ai en root dir C++ : MyProject/trunk et les chemins de generation pour les fichiers de chaque package sont définits en relatif par rapport au root dir, par exemple include/package1/

Dans "generation settings dialog" j'ai mis #include with root relative path et du coup l'include generé ressemble à #include "include/package1/MyClass.h"
ce qui pose problème à l'ide pour trouver le fichier.

Je pense bien que bouml ne peut pas deviner qu'on a un repertoire particulier pour les include, du coup est-il possible de désactiver la generation automatique de cet include afin de l'ajouter à la main sous la forme que je veux ?

Merci d'avance,
Cordialement

[bruno_pages]

Bonjour,

le générateur connaît (heureusement) l'emplacement des fichiers générés, par contre il ne sait pas que vous avez des options de compilation indiquant différents chemins (option -I de gcc), donc en particulier que vous spécifier de chercher sous include.

si vous ne pouvez ni utiliser des chemins relatifs (tout court ou à la racine) ni des chemins absolus ou absence de chemin il faut en effet demander au générateur de ne pas produire de lui même les #include. Pour cela il faut retirer les formes ${includes} dans les définitions C++ des artifacts et mettre vos #include à la place.

Le fait que votre IDE impose ainsi l'arbre des répertoires et ce genre de chemins de recherche des #include est assez bizarre

[Harooold]

Bonjour,

Metci pour la réponse.

J'ai effectivement été ammené à enlever le ${includes} pour chacune de mes classes et le remplacer par le bon #include. Mais vu qu'il y a un 's', j'imagine que l'include generé ne sera pas le seul à être enlevé, si ?

La hierarchie des dossiers n'est pas imposée par l'IDE mais par le projet pour lequel je vais développer un plugin en faisant de l'UML, du coup je n'y touche pas et fais avec !

Un autre petite question ( j'en profite ), au niveau des types externes template. J'ai une librairie externe gérant les pointeurs intelligents se nommant osg::ref_ptr <T>, où il faut précisé la classe dont il va garder une instance.

Comment les introduire dans bouml ? J'ai crée dans un premier temps un package OSG dans lequel j'ai crée une classe template ref_ptr mais si dans mes classes j'ajoute un attribut ref_ptr, je n'ai pas d'onglet parametrized dessus pour pouvoir spécifier T et l'attribut est generé en C++ comme ref_ptr <T> ...
Je suis en train de regarder pour l'ajouter en tant que type externe, comme pour les std::vector par exemple, mais ici je ne trouve pas comment spécifier que c'est un template.

Après cela je pense que ma configuration de bouml sera fin prête !
Merci d'avance,
Cordialement,
Harold

[bruno_pages]

Envoyé par Harooold

vu qu'il y a un 's', j'imagine que l'include generé ne sera pas le seul à être enlevé

tout les #includes sont produits par ${includes}, il s'agit de la définition de l'artifact c.a.d. du couple de fichiers en-tête/source, et plusieurs classes peuvent bien-sûr être associées à un même artifact

Envoyé par Harooold

...J'ai une librairie externe...

à partir du moment où les classes de cette lib ne doivent pas être produites il est préférable de ne pas définir ces classes comme des classes standard, et donc soit ne de pas les définir du tout soit de les définir comme étant des classes 'externes'

si vous ne définissez pas ces classes alors vous typerez un attribut avec un texte comme osg::ref_ptr <machin> un peu de la même façon que si le type de l'attribut était int. Mais vous pouvez aussi dire que le type est osg::ref_ptr et le stéréotype machin avec la définition c++ ${type}<$stereotype}>

si vous les définissez comme des classes externes il faut que le code produit pour elles soit osg::ref_ptr, c.a.d. sans le paramètre actuel, vous pourez toujours typer un attribut avec un texte comme osg::ref_ptr <machin> mais aussi avec le type osg::ref_ptr et la définition c++ ...${type}<machin> ou en mettant le stéréotype machin avec la définition c++ ...${type}<${stereotype}>. Puisque la classe osg::ref_ptr existe vous pouvez également utiliser une relation vers celle-ci et non vous limiter aux seuls attributs.

Envoyé par Harooold

je n'ai pas d'onglet parametrized dessus pour pouvoir spécifier T

cet onglet permet de définir les paramètres formels (le T de template<typename T> class osg::ref_ptr{ }; par exemple), si vous parlez de paramètre actuel (le machin de la définition de l'attribut osg::ref_ptr<machin> attr) c'est autre chose. Si vous définissez une classe héritant de classe(s) template alors vous aurez un onglet instantiate, mais seulement dans ce cas.

vous pouvez aussi définir le type rpmachin comme étant typedef osg::ref_ptr<machin> rpmachin, créez la classe rpmachin, faites la hériter de osg::ref_ptr puis editez la pour lui mettre le stéréotype typedef, mettre le paramètre actuel à machin et allez dans l'onglet C++ pour demander la définition par défaut. rpmachin est utilisable comme n'importe qu'elle autre classe.