De l'importance de la règle module
Arkanosis
Indépendamment du problème d'imports mutuellement récursifs, le
problème de "is in multiple defined" (paye ton message d'erreur)
provient effectivement de l'absence de la règle module, mais pourquoi
? (j'ai mis du temps à comprendre)
D'après les specs :
1) Modules have a one-to-one correspondence with source files. The
module name is the file name with the path and extension stripped off.
2) The ModuleDeclaration sets the name of the module and what package
it belongs to. If absent, the module name is taken to be the same name
(stripped of path and extension) of the source file name.
En fait c'est assez clair, ce n'est juste pas immédiat :
- quand il n'y a pas de package (répertoire physique), tout va bien
- quand il y a un ou plusieurs packages imbriqués, le nom du fichier
privé du chemin et de l'extension diffère du nom du module
Exemple :
main.d : nom du fichier : main, nom du module : main => OK
frames/deamon.d : nom du fichier : deamon, nom du module : frames.deamon => KO
Donc, en l'absence de la règle module, mon fichier déclare le module
"deamon", mais dans main on importera quand même frames.deamon (car
deamon.d n'existe pas physiquement à côté de main.d) ; d'où un module
défini dans deux package : la racine et frames. Ce que notre
compilateur adoré traduit de façon très claire (ou pas ?) par "in
multiple defined".
Alors, que notre compilo marche bien ou pas, il sera de toutes façon
bien meilleur au niveau des messages d'erreur (pour info, j'utilise
dmd 2.013).
Un dernier message d'erreur, que j'ai eu avec dsss et rebuild : "Could
not detect versions", ce qui veut dire, c'est évident, que le linker
de dmc n'est pas présent dans le path (et pour cause, il n'est pas
fourni de base avec dmd). Trivial je vous dis.
Ceci dit, après tout ce temps perdu, je crois que j'ai une bien
meilleure vision du fonctionnement des modules, et j'ai un combo dmd2
/ ddbg / descent / rebuild / dsss / hg qui marche du tonnerre :p
--
Arkanosis
Alexandre Bique
> Iop !
Salut,
> Indépendamment du problème d'imports mutuellement récursifs, le
> problème de "is in multiple defined" (paye ton message d'erreur)
> provient effectivement de l'absence de la règle module, mais pourquoi
> ? (j'ai mis du temps à comprendre)
>
> D'après les specs :
> 1) Modules have a one-to-one correspondence with source files. The
> module name is the file name with the path and extension stripped off.
> 2) The ModuleDeclaration sets the name of the module and what package
> it belongs to. If absent, the module name is taken to be the same name
> (stripped of path and extension) of the source file name.
>
> En fait c'est assez clair, ce n'est juste pas immédiat :
> - quand il n'y a pas de package (répertoire physique), tout va bien
> - quand il y a un ou plusieurs packages imbriqués, le nom du fichier
> privé du chemin et de l'extension diffère du nom du module
>
> Exemple :
> main.d : nom du fichier : main, nom du module : main => OK
> frames/deamon.d : nom du fichier : deamon, nom du module : frames.deamon =>
> KO
>
> Donc, en l'absence de la règle module, mon fichier déclare le module
> "deamon", mais dans main on importera quand même frames.deamon (car
> deamon.d n'existe pas physiquement à côté de main.d) ; d'où un module
> défini dans deux package : la racine et frames. Ce que notre
> compilateur adoré traduit de façon très claire (ou pas ?) par "in
> multiple defined".
Je confirme ton observation avec un nm :
_D8compiler4lang1d3ast7Visitor14DefaultVisitor5visitMFC8compiler4lang1d3ast4Node4NodeZv
<=>
compiler.lang.ast.Visitor.DefaultVisitor::visit(compiler.lang.ast.Node.Node)
ou l'on voit tres clairement le nom complet modules.Classname apparaitre dans
les symboles quand le module est declare. Souvenez-vous des symboles precedant
quand la ligne module n'etait pas declaree.
> Alors, que notre compilo marche bien ou pas, il sera de toutes façon
> bien meilleur au niveau des messages d'erreur (pour info, j'utilise
> dmd 2.013).
Il ne faudra pas oublier la localisation !
Par contre pourquoi dmd 2.013 ? Tango et Apaged compilent avec ?
> Un dernier message d'erreur, que j'ai eu avec dsss et rebuild : "Could
> not detect versions", ce qui veut dire, c'est évident, que le linker
> de dmc n'est pas présent dans le path (et pour cause, il n'est pas
> fourni de base avec dmd). Trivial je vous dis.
>
> Ceci dit, après tout ce temps perdu, je crois que j'ai une bien
> meilleure vision du fonctionnement des modules, et j'ai un combo dmd2
> / ddbg / descent / rebuild / dsss / hg qui marche du tonnerre :p
ddbg c'est sous windows ? Ca donne quoi ? Pour descent tu le compiles du svn
ou l'autheur met sont plugin regulierement a jour sur son depot ?
Sinon pour trigger ce genre de bugs j'imagine que tu as bosse sur le visiteur,
tu as reussis a faire des choses sympas ? :-)
--
Alexandre Bique (bique.a...@gmail.com)
Epita 2009 - Yaka - GISTR
Port. +336 19 42 85 26
Arkanosis
> Par contre pourquoi dmd 2.013 ? Tango et Apaged compilent avec ?
> ddbg c'est sous windows ? Ca donne quoi ?
Oué, c'est sous windows, c'est sensé donner ça :
http://www.dsource.org/projects/descent/wiki/DebuggingPrograms
En vrai, j'ai encore des problèmes avec les symboles en debug.
> Pour descent tu le compiles du svn ou l'autheur met sont plugin regulierement a jour sur son depot ?
Depuis le svn ; c'est la méthode normale : le serveur de mises à jour
d'eclipse est le trunk du svn.
> Sinon pour trigger ce genre de bugs j'imagine que tu as bosse sur le visiteur,
> tu as reussis a faire des choses sympas ? :-)
Euh non, tu vas être déçu, je bosse sur mon proj de SCIA...
--
Arkanosis
Alexandre Bique
Stylee :-)
--
Alexandre Bique (bique.a...@gmail.com)
Epita 2009 - GISTR - Yaka