Question

J'ai une grande base de code c ++ existante. Généralement, les utilisateurs de la base de code modifient la source avec gvim, mais nous aimerions commencer à utiliser les fonctionnalités intéressantes de l'EDI dans Eclipse. La base de code a une hiérarchie de répertoires étendue, mais les fichiers source utilisent des directives d'inclusion sans chemin d'accès en raison d'une certaine voodoo que nous utilisons dans notre processus de construction. Lorsque je lie le code source à mon projet dans Eclipse, l'indexeur se plaint de ne trouver aucun fichier d'en-tête (car nous ne spécifions pas les chemins dans nos inclus.) Si j'ajoute manuellement les répertoires de l'espace de travail au chemin d'inclusion, tout fonctionne à merveille, mais il est évidemment impossible d'ajouter des centaines de répertoires manuellement. Y aurait-il une méthode simple pour dire à Eclipse de rechercher n'importe où dans le projet les fichiers d'inclusion sans avoir à les ajouter un par un? Sinon, quelqu'un peut-il suggérer un bon point de départ, comme la classe à étendre, pour écrire un plugin simplement pour scanner le projet lors de la création / modification et pour ajouter tous les répertoires au chemin d'inclusion par programme?

Était-ce utile?

La solution

Cette fonctionnalité a déjà été implémentée dans le flux de développement CDT actuel et sera disponible dans CDT 6.0, qui sera publiée avec Eclipse 3.5 en juin 2009.

En gros, si vous avez un #include et que le fichier d’en-tête existe quelque part dans votre projet, CDT pourra le trouver sans avoir à configurer manuellement les chemins d’inclusion.

Si vous avez besoin de cette fonctionnalité maintenant, vous pouvez télécharger et installer la dernière version de développement de CDT.

Eclipse Bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=21356
Dernières versions de CDT 6.0: http://download.eclipse.org/tools/cdt/builds/6.0.0 /index.html

Autres conseils

CDT gère les chemins de construction en consultant le fichier .cdtbuild xml situé dans la base du répertoire de vos projets (il peut s'agir d'un nom différent sous Windows ... pas sûr)

En cela, vous devriez voir quelque chose comme

<option id="gnu.c.compiler.option.include.paths....>
<listoptionValue builtIn="false" value="&quot;${workspace_loc:/some/path}$quot;" />
<listOptionValue ... />

...
</option>

C'est ici que sont placés tous les chemins de construction que vous configurez dans l'interface graphique. Il devrait être assez facile d’ajouter tous les répertoires à cela en utilisant un simple script Perl pour parcourir le projet et générer toutes les entrées listOptionValue.

Ce n’est évidemment pas la méthode idéale. Mais, curieux de savoir quel système de compilation migrez-vous, s'il est basé sur make, vous devriez pouvoir obtenir eclipse pour utiliser vos fichiers make.

La lecture de l'article .22._How_do_I_get_rid_th_them.3F "rel =" nofollow noreferrer "> cette entrée de la FAQ Eclipse CDT , il semblerait que Eclipse puisse générer automatiquement une liste de répertoires d'inclusion si vous démarrez votre construction à partir d'Eclipse et si gcc / g ++ avant de démarrer réellement gcc / g ++ . Vous pouvez modifier la manière dont Eclipse commence une construction en allant dans Propriétés du projet, puis en sélectionnant la catégorie Construction C / C ++ et en cherchant l’option Commande de construction à droite de la boîte de dialogue.

En fonction de la quantité de vaudou que vous effectuez dans votre processus de construction, Eclipse risque de ne pas être en mesure d'analyser correctement vos fichiers source, en particulier si vous avez des en-têtes portant le même nom pour différents fichiers source. Si vous voulez vraiment tirer le meilleur parti d’Eclipse, vous devez vous assurer que, quelle que soit la configuration choisie, vous ne risquez pas de dérouter l’analyseur. Personnellement, je recommanderais un processus simple de mise en page et de construction.

Pour ce qui est de la question, ajouter les répertoires un par un est quasiment votre meilleur pari.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top