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)