2009-07-08 5 views
3

Dans certains de mes projets VS 2005, lorsque je modifie un fichier include, certains fichiers cpp ne sont pas reconstruits, même s'ils contiennent une simple ligne #include.Comment Visual Studio sait-il quels fichiers cpp sont à reconstruire lorsqu'un fichier include est modifié?

Est-ce un bug connu, ou quelque chose d'étrange à propos des projets? Existe-t-il des informations sur la manière dont VS élabore les dépendances et puis-je voir les fichiers pour cela?

btw J'ai essayé quelques googling mais je n'ai rien trouvé à ce sujet. J'ai probablement besoin du bon terme de recherche ...

Répondre

2

J'ai rencontré ce problème de temps en temps, et avec d'autres IDE, pas seulement VS. Il semble que leur arbre de dépendance interne s'écarte parfois de la réalité. Dans ces cas, j'ai trouvé la suppression des en-têtes pré-compilés (c'est important) et faire une reconstruction complète résout toujours le problème. Heureusement, cela n'arrive pas souvent.

+0

Oui, la reconstruction complète le corrige mais prend environ 40 minutes. J'essaie d'obtenir des builds sans surveillance sur ma machine. – danio

+0

@danio: Je me souviens d'avoir de tels problèmes. Dans ce cas, j'ai soit redémarré Visual Studio, soit fait la reconstruction. Pourquoi avez-vous tout reconstruire? Tu ne peux pas reconstruire le projet seulement? – ovanes

+0

@ovanes Oui, reconstruire juste le problème des projets est plus rapide, mais les trouver peut prendre beaucoup de temps. Avoir à décrypter les erreurs de l'éditeur de liens pour déterminer quelles bibliothèques sont erronées, reconstruire chacune d'elles, puis reconstruire la solution et espérer les avoir toutes saisies. – danio

2

Pour être honnête, je n'ai jamais été confronté à un tel problème avec Visual Studio. Votre CPP doit également être reconstruit s'il inclut l'en-tête. La seule raison pour laquelle je peux arriver: le même fichier d'inclusion provient de deux sources différentes.

Vous pouvez essayer de déboguer ceci au moment de la compilation, en permettant au préprocesseur de sortir les fichiers prétraités. Cliquez sur le fichier CPP aller aux propriétés, puis à C/C++ -> préprocesseur et sélectionnez dans "Générer un fichier prétraité" l'élément avec ou sans numéros de ligne.

Allez vous inclure fichier mis les pragmas autour de vos nouvelles définitions ajoutées comme:

#pragma starting_definition_X 
... 
#pragma ending_definition_X 

Maintenant, tout compiler. Il y aura un fichier nouvellement créé avec le même nom que CPP mais avec l'extension .I (ou .i).

Faites une recherche si vos pragmas sont là. Sinon, votre inclusion vient d'un autre endroit.

Si vous utilisez des en-têtes précompilés, vous devez reconstruire cpp. Il y a aussi une déclaration pragma une fois dans MS VC, qui analyse le fichier include une seule fois, mais qui devrait quand même recompiler le fichier cpp.

Espoir qui aide,
Ovanes

+0

Les fichiers d'en-tête utilisent tous #pragma fois ou #ifdef gardes donc je ne pense pas que ce soit la cause du problème. Intéressant cependant que la sortie du préprocesseur puisse être stockée: merci cela pourrait être utile dans le futur ... – danio

+0

Oui, je l'ai beaucoup utilisé quand a fait un certain type de métaprogrammation de pré-processeur mixte et de méta-programmation commune. C'était le seul moyen de déboguer la génération de code. La bonne chose est que vous pouvez mettre n'importe quel pragmas dans le fichier header ou cpp, et les trouver plus tard dans le fichier pré-traité, car les fichiers pré-traités sont généralement très volumineux, en raison des optimisations. doit réécrire le fichier chaque fois que smth est inséré au milieu. Puisque les pragmas restent dans le fichier pp, vous pouvez simplement les rechercher et trouver votre extrait d'intérêt. – ovanes

0

Visual Studio compare les horodateurs sur les fichiers. Vous devriez donc vérifier que l'horloge de votre système est correctement configurée et qu'aucun des fichiers ne comporte un horodatage bizarre. Regardez les fichiers include, les fichiers cpp, les fichiers pch et les fichiers obj et assurez-vous que tous les horodateurs ont l'air raisonnables. En particulier, assurez-vous qu'aucun d'entre eux sont dans le futur.

+0

merci, mais les temps semblent OK. .h est plus récent que .obj qui est plus récent que .cpp. Nous n'utilisons pas pch ici. – danio

1

Avez-vous activé l'option "Minimal rebuild"?

+0

Non, mais le fichier idb semble toujours être généré. Je verrai si je peux obtenir n'importe où avec ces fichiers ... – danio

0

Les fichiers .h ont-ils été ajoutés dans le projet? Sinon, alors vs peut-être incapable de trouver la dépendance.

+0

Non, ils ne sont pas dans le projet (ne demandez pas ...). Je ne pense pas que cela devrait être nécessaire. – danio

0

Merci pour toutes les réponses qu'ils m'ont aidé à me diriger dans la bonne direction.

J'ai découvert que la suppression du fichier idb et la reconstruction permettraient ensuite aux modifications ultérieures de fichiers .h de générer les fichiers .cpp corrects. Cependant, cela provoque la reconstruction de l'ensemble du projet, ce qui me ramène à la suggestion de Neil Butterworth de procéder à une reconstruction complète. Je ne pense pas que je puisse faire grand-chose d'autre à ce sujet.En passant, en regardant les mauvais et bons fichiers idb je peux voir que le fichier cpp qui n'a pas été construit n'est pas dans le mauvais idb, alors qu'il est dans le bon idb. Le fichier d'en-tête en cours de modification est mentionné plusieurs fois dans les deux fichiers.

win_pdbx(download) peut extraire le fichier idb et moyix a publié some information sur les flux dans ces fichiers. Le flux 4 contient les chemins de fichier des fichiers cpp mais je n'ai pas pu déterminer le format.

Questions connexes