Pourquoi cl.exe ne génère-t-il aucune sortie quand je l'appelle de Perl?

Question

J'ai un problème étrange avec l'exécution de cl.exe qui m'a dérouté. Dans une grande solution VS2008 composée de projets C/C++, j'ai un projet qui exécute des scripts pour faire un traitement supplémentaire. Le projet consiste en un événement de pré-construction, qui appelle un script Perl (ActiveState Perl est sur la machine). Ce script Perl appelle ensuite cl.exe avec /E pour générer une sortie prétraite qui est redirigée vers un fichier. La ligne en Perl ressemble à ceci:

my $foo = `"\path\to\cl.exe" @args.rsp >out.txt 2>err.txt`; 

args.rsp est un fichier texte qui contient un tas de args de ligne de commande pour cl.exe, y compris /E pour obtenir une sortie pré-processeur sur la sortie standard.

Cette ligne de commande fonctionne exactement comme prévu lorsqu'il est exécuté à partir de l'invite de commande VS2008. La construction du projet fonctionne également très bien sur ma machine Windows XP. Cependant, sur ma nouvelle boîte de Windows 7, quand je construis le projet, out.txt finit vide. Je devrais également ajouter que sur certaines des boîtes Windows 7 de mon collègue, cela fonctionne très bien, et sur d'autres pas.

Il est clair que la différence de configuration, il y a une sorte qui se passe, mais je suis à une perte de ce qu'il peut être. Nous avons vérifié les versions correspondantes de VS2008 SP1 et ActiveState Perl. J'ai essayé des solutions de contournement innombrables dans le script Perl - à l'aide system() au lieu de les apostrophes inverses, en utilisant cl.exe /P à la sortie d'un fichier, puis déplacer le fichier (le fichier est vide), désenclencher la variable d'environnement VS_UNICODE_OUTPUT (pas d'effet). Rien n'a changé le comportement - la sortie est générée lorsque la ligne de commande est exécutée manuellement, mais pas quand elle est exécutée dans l'événement de pré-construction pour ce projet.

Des idées sur ce genre de problème de configuration peut être la cause? Je suis à peu près hors des avenues à poursuivre.

Answer 1

Cela me semble être un problème ACL. Vous pouvez modifier les fenêtres pour consigner les problèmes d'accès, puis vérifier le journal des événements pour voir quels utilisateurs obtiennent des erreurs d'accès refusé. Je crois que le paramètre est dans Local Policy | Politique d'audit | Audit de l'accès aux objets

Answer 2

Vérifiez le code de sortie de votre programme. Vous pouvez créer votre nom d'exécutable de manière portable en utilisant quelque chose comme File::Spec. Vérifiez également que @args n'interpole pas. Vous voudrez peut-être imprimer votre ligne de commande avant de l'exécuter pour vérifier si c'est ce que vous voulez. Qu'est-ce qui reste votre fichier err.txt?

Answer 3

Wow, la solution à ce fini par être un étranger beaucoup que prévu. La machine sur laquelle je travaille (et les autres collègues qui sont également confrontés au problème) est un Mac Pro avec bootcamp et Windows 7 installé. Cela provoque C: avoir le Windows drive et E: avoir le mac drive. Cela provoque un problème car l'événement de pré-construction a quelques lignes qui testent chaque lettre de lecteur pour voir s'il y a un lecteur là, et s'il y a, ajoute X: \ Perl \ bin au chemin. Même si E: \ Perl \ bin n'existe pas, il est ajouté au chemin. Plus tard, le script perl s'exécute, puis appelle cl.exe et, pour une raison quelconque, avoir un répertoire dans le lecteur mac provoque l'échec de cl.exe. Pourquoi? Je n'ai aucune idée. Quoi qu'il en soit, supprimer le répertoire du lecteur mac du chemin résout le problème!

Merci pour vos yeux tout le monde.