[Qt4] Fichiers (cpp) ayant les même noms

Fichiers (cpp) ayant les même noms [Qt4] - C++ - Programmation

Marsh Posté le 30-04-2007 à 21:30:31    

Yop all,
Petit problème très simple à comprendre (mais pas à résoudre apparemment).
 
Pour un projet donné j'ai plusieurs fichiers ayant les mêmes noms mais dans des dossiers différents, par exemple :

./NS1/poulpe.h
./NS1/poulpe.cpp
./NS2/poulpe.h
./NS2/poulpe.cp
./projet.pro
./Makefile


 
qmake me génère un Makefile dans lequels les fichiers 'obj' ont pour nom l'unité de compilation, c'est à dire le .cpp. Tous ces jolis fichiers 'obj' vont se retrouver dans le même dossier, par exemple ./Debug.
Vous comprenez vite mon problème, pour l'exemple donné plus haut, deux fichiers 'poulpe.o' vont être créés dans le même dossier... par très jojo.
 
Il y a plusieurs solutions permettant de contourner le problème comme par exemple prefixer les fichiers avec le nom de leur dossier ou modifier le Makefile "à la main". Ces solutions ne me conviennent pas, la première introduit une règle un peu barbare et la deuxième oblige d'écrire un petit script annexe qui rend un peu plus complexe la compilation (comme si ca ne l'était déjà pas assez avec Qt, moc toussa..)
 
Quelqu'un aurait une réponse à mon problème ?
Merci d'avance !


Message édité par Ummon le 30-04-2007 à 21:31:10
Reply

Marsh Posté le 30-04-2007 à 21:30:31   

Reply

Marsh Posté le 01-05-2007 à 18:54:09    

A en voir l'apparence des chemins que tu utilise, tu dois surement être sous *nix. Si c'est le cas, je ne pense pas que ce soit possible de prendre 2 fichiers .h, de les transformer en .o puis de les mettre dans le même dossier, y'aura toujours un probleme de "fichier déja existant, voulez vous le remplacer".  
Peux-tu détailler un peu ce que tu essaie de faire, sans forcément dévoiler le code de ton soft ?

Reply

Marsh Posté le 01-05-2007 à 23:41:40    

Salut,
 
Ce n'est effectivement pas possible. Et je me joins à tom5025 pour en savoir un peu plus sur le 'pourquoi'.

Reply

Marsh Posté le 02-05-2007 à 00:06:52    

Merci pour vos réponses.
La raison est simple, comme des personnes différentes travaillent sur le même projet mais dans des namespaces différents ils ne sont pas forcément au courant de ce qui se fait dans les autres namespaces.
Il se peut très bien qu'un fichier ./NS1/rep1/tools.h soit créé alors qu'un fichier portant le même nom se trouve déjà dans ./NS2/rep2/.
C'est aussi un peu le but des namespaces, de créer des domaines de noms.
 
Par contre, par rapport à se que dit tom5025, le nom d'un fichier .o n'a, a priori, rien à voir avec le nom du fichier correspondant, on pourrait très bien imaginer que le nom du fichier .o soit le chemin complet + le nom du fichier. C'est simplement les outils de QT qui travaillent comme ca.
 
Si je ne trouve pas de solution simple avec QT, je ferai simplement du post traitement sur les makefiles.

Reply

Marsh Posté le 02-05-2007 à 00:23:55    

Ummon a écrit :

Merci pour vos réponses.
La raison est simple, comme des personnes différentes travaillent sur le même projet mais dans des namespaces différents ils ne sont pas forcément au courant de ce qui se fait dans les autres namespaces.


Ca, c'est grave [:quardelitre]

Ummon a écrit :

Il se peut très bien qu'un fichier ./NS1/rep1/tools.h soit créé alors qu'un fichier portant le même nom se trouve déjà dans ./NS2/rep2/.
C'est aussi un peu le but des namespaces, de créer des domaines de noms.


Des espaces de nommage *dans le code* :/
Les namespaces sont pas là pour supporter des noms de fichiers différent... Si tu te fais jeter à la compilation, et qu'il te dit regarder la déclaration de machin dans tools.h, c'est bien de savoir duquel on parle. (Même si tu as tout le chemin, je pense que comme tout le monde tu as autre chose à faire que de décrypter un message d'erreur quand c'est possible.)

Ummon a écrit :

Par contre, par rapport à se que dit tom5025, le nom d'un fichier .o n'a, a priori, rien à voir avec le nom du fichier correspondant, on pourrait très bien imaginer que le nom du fichier .o soit le chemin complet + le nom du fichier. C'est simplement les outils de QT qui travaillent comme ca.

 

Si je ne trouve pas de solution simple avec QT, je ferai simplement du post traitement sur les makefiles.


Avec les .pro, il y a peut-être moyen de te faire une tambouille à base de:
> variables
> dirname
> contains
> for
> et ptet d'autres.
(cf la doc qmake sur les fonctions.)

Message cité 1 fois
Message édité par IrmatDen le 02-05-2007 à 00:24:10
Reply

Marsh Posté le 02-05-2007 à 08:22:08    

IrmatDen a écrit :

Ca, c'est grave [:quardelitre]


Pourquoi ? tu peux t'expliquer ?
Des interfaces (partie publique d'un sous-système) sont définis entre les sous-systèmes qui sont gérés à l'aide de namespaces. La partie privée du sous-système n'est absolument pas visible par les autres, cela permet d'avoir une indépendance entre les sous-systèmes. Évidemment que les sous-systèmes pourrait être géré avec des lib statiques ou dynamiques, mais ce n'est pas nécessaire dans mon projet.
Chaque personne est responsable d'un sous-système, il s'occupe de son sous-système et pas des autres, bien sur rien n'empêche qu'il aille jeter un oeil sur ce que font les autres personnes.
 
 

IrmatDen a écrit :

Des espaces de nommage *dans le code* :/
Les namespaces sont pas là pour supporter des noms de fichiers différent... Si tu te fais jeter à la compilation, et qu'il te dit regarder la déclaration de machin dans tools.h, c'est bien de savoir duquel on parle. (Même si tu as tout le chemin, je pense que comme tout le monde tu as autre chose à faire que de décrypter un message d'erreur quand c'est possible.)


C'est clair que les namespaces n'ont pas de lien avec le nom des fichiers, simplement j'ai posé comme convention que le nom du fichier correspond au nom de la classe qu'il contient et que les dossiers à la racine correspondent aux différents namespaces.
 

IrmatDen a écrit :


Avec les .pro, il y a peut-être moyen de te faire une tambouille à base de:
> variables
> dirname
> contains
> for
> et ptet d'autres.
(cf la doc qmake sur les fonctions.)


Merci pour l'url, j'irai voir ce que je peux faire.

Reply

Marsh Posté le 02-05-2007 à 09:39:38    

A titre d'information, le projet est simplement un petit jeu que j'ai commencé avec des potes : http://ppp.euphorik.ch

Reply

Marsh Posté le 02-05-2007 à 12:22:49    

Ummon a écrit :

Pourquoi ? tu peux t'expliquer ?
Des interfaces (partie publique d'un sous-système) sont définis entre les sous-systèmes qui sont gérés à l'aide de namespaces. La partie privée du sous-système n'est absolument pas visible par les autres, cela permet d'avoir une indépendance entre les sous-systèmes. Évidemment que les sous-systèmes pourrait être géré avec des lib statiques ou dynamiques, mais ce n'est pas nécessaire dans mon projet.
Chaque personne est responsable d'un sous-système, il s'occupe de son sous-système et pas des autres, bien sur rien n'empêche qu'il aille jeter un oeil sur ce que font les autres personnes.
 
C'est clair que les namespaces n'ont pas de lien avec le nom des fichiers, simplement j'ai posé comme convention que le nom du fichier correspond au nom de la classe qu'il contient et que les dossiers à la racine correspondent aux différents namespaces.


Regarde quelques gros projets dont les sources sont dispos:
> Qt
> Ogre
> wxWidgets
> et une quantité innombrable d'autres
Aucun n'a 2 fois le même nom de fichier.
 
Si tu as 2 classes Poulpe, malgré que ce soit dans 2 namespaces différents, il faudrait au moins pour bien faire que la différence soit nommée. Admettons poulpe_phys.h/.cpp et poulpe_behavior.h/.cpp si la différence réside dans le but du comportement.
Ceci dit, avoir 2 fois la même classe, même dans 2 namespaces, est-ce rééllement utile?
N'y aurait-il pas intérêt à regrouper les parties commune dans un module core par exemple?

Reply

Marsh Posté le 02-05-2007 à 14:44:48    

IrmatDen a écrit :

Regarde quelques gros projets dont les sources sont dispos:
Si tu as 2 classes Poulpe, malgré que ce soit dans 2 namespaces différents, il faudrait au moins pour bien faire que la différence soit nommée. Admettons poulpe_phys.h/.cpp et poulpe_behavior.h/.cpp si la différence réside dans le but du comportement.
Ceci dit, avoir 2 fois la même classe, même dans 2 namespaces, est-ce rééllement utile?
N'y aurait-il pas intérêt à regrouper les parties commune dans un module core par exemple?

 

Et pourquoi pas phys/poulpe.h/.cpp (Phys :: Poulpe) et behavior/poulpe.h/.cpp (Behavior :: Poulpe) ?
La question n'est pas de savoir si c'est utile ou pas c'est simplement que ça peut arriver sans le vouloir.

Message cité 1 fois
Message édité par Ummon le 02-05-2007 à 14:47:51
Reply

Marsh Posté le 02-05-2007 à 15:41:48    

Ummon a écrit :

Et pourquoi pas phys/poulpe.h/.cpp (Phys :: Poulpe) et behavior/poulpe.h/.cpp (Behavior :: Poulpe) ?


Pour éviter le kaka dans lequel tu te retrouves maintenant?
Tout le monde arrive à éviter ce genre de situation.

Reply

Marsh Posté le 02-05-2007 à 15:41:48   

Reply

Marsh Posté le 30-10-2007 à 14:56:04    

Petit up car je n'ai toujours pas résolu mon problème :(

Reply

Marsh Posté le 30-10-2007 à 15:57:43    

Regarde peut-être du côté de cmake? Il est plus puissant que qmake, donc peut-être ont-ils prévu ça, ou plus simplement, peut-être qu'il y a la souplesse qu'il te faut.
 
qmake seul ne te le fera pas. Il te faudrait développer des scripts pour faire un traitement et dupliquer en renommant les fichiers en phase de preprocess, ce qui reste particulièrement gore (à mon goût...).

Reply

Marsh Posté le 30-10-2007 à 17:03:03    

Merci pour ta réponse, je vais regarder du coté de cmake... éventuellement si je n'ai pas de solution je créerai plusieurs lib statique, une par namespace.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed