Discussion :

[mikeOSX]

Bonjour à tous,

J'ai un problème lorsque je compile un projet sous visual c++ 2005.
Dans mes propriétés du projet, j'ai mis en répertoire intermédiaire : "D:\temp\[...]" (en chemin absolu)
Mon projet se trouve dans D:\[........]\monProj.vcproj

Lorsque je compile, dans les traces de sortie, il me met tous les chemins, en chemin relatif , ../../../../../../[...]/temp/[...]/xxx.obj
Pourtant, dans les propriétés, on peut voir la ligne de commande, et dans celle ci, il y a bien le chemin absolu.

Le gros problème, c'est que dans certains cas, lorsqu'on fait [cheminVcproj]\[RepInterRelatif]\[fichier], et bien sa taille dépasse les 255 caractères, ce que windows ne gère pas (je suis sous XP, mais j'ai l'impression que sur 7 c'est la même chose)
Et visual me dit qu'il n'arrive pas a trouver le fichier, alors que tout est bon (fichier présent, chemin relatif correct...), car windows l'envoie bouler.

Si je réduis la taille des noms des fichiers (qui donne moins de 255 caractères), ça marche.
Si je change le lecteur (au lieu de D:\temp\, j'ai c:\temp), ca marche, car il ne peut pas transformer le chemin en chemin relatif.

Ma question :
Y a t il une option dans le projet/solution/visual... forçant visual à utiliser le chemin absolu (qui est fourni) et non le chemin relatif (qu'il créé lui même) ?

J'ai d'autres solutions pour palier le problème de taille du chemin, mais que je trouve "crade" par rapport à mes besoins, donc je ne cherche pas un contournement.
Je n'ai pas la possibilité de changer d'OS/version de visual...
Je suis en train de changer de gestion de conf de mon soft et j'ai tout un tas de problème dont celui la.

Si vous avez des questions, que tout n'est pas clair... n’hésitez pas, j'essaierai de préciser au mieux.

En cous remerciant.

Mike

[bacelar]

et bien sa taille dépasse les 255 caractères, ce que windows ne gère pas (je suis sous XP, mais j'ai l'impression que sur 7 c'est la même chose)

Windows le gère très bien, jusqu'à 32k même.
Il faut juste que le système de fichier ne soit pas FAT mais NTFS et faire attention lors d'utilisations de ces chaines dans des shells ayant eux une limite.

Si je réduis la taille des noms des fichiers (qui donne moins de 255 caractères), ça marche.

Vraisemblablement une limitation du shell. Faut aussi voir que vous vous coltinez un compilateur vieux de 11 ans !!!

Il y a très certainement une solution directement à votre problème, mais j'ai quand même un gros problèmes avec l'utilisation de "D:\temp\[...]" en dur dans un projet.

Moi, j'ai tendance à mettre les fichiers intermédiaires dans l'arborescence de la solution, pour pas tout polluer.
Sinon, si une solution ne peut pas tout regrouper, j'ai tendance à utiliser un "lecteur réseau" pour que tout soit bien rangé à la racine de ce lecteur et que les membres de l'équipe n'ont qu'à créer le même "lecteur réseau", contrairement à forcement avoir un "D:\temp\[...]" avec les droits nécessaires.

[Ehonn]

Windows le gère très bien, jusqu'à 32k même.

La limitation de 32k est vraie pour le système de fichier NTFS mais l'API de Windows (y compris Windows 10), celle utilisée pour l'explorateur de fichiers, ne gère pas correctement les fichiers dont le chemin total fait plus de ~256 caractères.
(Si quelqu'un a une solution autre que renommer les dossiers et/ou fichier et autre que monter un nouveau lecteur pour faire un raccourci, je suis preneur. Il faut utiliser des logiciels alternatifs ?)

[foetus]

Windows 10 : Microsoft met silencieusement fin à la limitation à 260 caractères pour les chemins d'accès dans la Build 14352

[Médinoc]

En dehors de la "nouveauté" de Windows 10, pour utiliser des noms de fichiers de plus de MAX_PATH (260) caractères, il faut passer par des chemins UNC (i.e. des chemins réseau).

[foetus]

J'en parle dans mon message des chemins UNC

[mikeOSX]

Bonjour, et merci pour vos réponses.

Vraisemblablement une limitation du shell. Faut aussi voir que vous vous coltinez un compilateur vieux de 11 ans !!!

Je suis bien conscient que je bosse sur des vieux trucs, mais je n'ai pas trop le choix

Il y a très certainement une solution directement à votre problème, mais j'ai quand même un gros problèmes avec l'utilisation de "D:\temp\[...]" en dur dans un projet.

Moi, j'ai tendance à mettre les fichiers intermédiaires dans l'arborescence de la solution, pour pas tout polluer.
Sinon, si une solution ne peut pas tout regrouper, j'ai tendance à utiliser un "lecteur réseau" pour que tout soit bien rangé à la racine de ce lecteur et que les membres de l'équipe n'ont qu'à créer le même "lecteur réseau", contrairement à forcement avoir un "D:\temp\[...]" avec les droits nécessaires.

A la base, on bossait sur Clearcase, donc surement pour éviter de polluer les vues/vobs... ils ont tout déplacé dans un chemin local (qui est sous forme de variable).
Il m'est possible de changer les chemins... mais c'est pas dans un premier temps ce que je recherche.
Mon but premier est que les personnes qui reprendront ce projet n'ait qu'a récupérer le code, et puisse compiler direct, sans avoir besoin de créer des répertoires, faire des subst.....
D’où le fait que j'essaie de trouver des solutions a ce genre de problème !

[bacelar]

sans avoir besoin de créer des répertoires, faire des subst.....

Dans mon cas, une simple commande "subst" indiquée dans le README du projet faisait l'affaire.(chaque dev avait sa propre configuration et gérait lui-même où il avait encore de l'espace disque)