Calling Python scripts as Visual Studio custom build step.

Bengt Richter bokr at oz.net
Thu Jan 24 01:59:02 EST 2002


On Wed, 23 Jan 2002 07:35:03 -0500, "Steve Holden" <sholden at holdenweb.com> wrote:

>"Tom Harris" <TomH at optiscan.com> wrote ...
>>
>> Microsoft Visual Studio allows the specification of custom sets of
>commands
>> to be run when a file is built. Usually the output (stdout & stderr) of
>> these commands is redirected to a log window. When MSVC runs a Python
>> script, however, the output is lost. It works fine if the command is a
>batch
>> file or a Perl script. This is on MSVC 6.0 on NT 4.0, with Python 2.1 or
>> 2.2.
>>
>> Is there a workaround? Apart from using a real OS of course.
>>
>One possibility: if you've just used the Python file's name as the command
>redirection is known to be dodgy under various Windows command interpreters.
>If you explicitly use the "python" command, with the Python filename as an
>argument, it's *possible* you'll get better results. But this is a guess. No
>promises.
>
It's probably a good guess, but there are a couple of other things that
could also prevent it from working, e.g.,

1. If your path is not set up when you run the C++ IDE to allow it to find
python.exe. You can obviously get around this by just specifying the whole path,
e.g., d:\python21]python.exe, or wherever you have it. Or you can make sure
the path includes it by setting it up in the control panel for your or systemwide use.

2. The similar problem of python's working directory, or paths to find whatever
script you are trying to execute. When the IDE executes python from the IDE,
the working directory should be the project directory (where the .dsp file is),
so you can put your scripts right there and not have to specify full path on them. 

I am a little surprised that perl worked for you, if you used the same pattern
of invocation, because the same problem (AFAIK) occurs for any program launched
via windows' file extension association, other than .exe, .cmd, .bat, and .com.

The output is not available for redirection unless you specify the interpreter
.exe itself in the command line. So if you had myPerlScript.pl blah blah, the
output (to stdout) would not be available. Maybe your working perl script did
all its work on files, and you didn't notice lack of stdout?

Anyway, it can be made to work. Here's a little test hello world program that includes
a time stamp definition in header file that's regenerated by python script if it's older
than the .c source:
---- the .c test program ---
/* testIDE.c */

#include "timestampheader.h"
#include <stdio.h>

int main(int argc, char* argv[])
{
	printf("Hello World! on %s\n",BUILDTIMESTAMP);
	return 0;
}
----the time stamp header generator script ----
#timestampheader.py
#writes a new timestampheader.h
import sys, time

f = open('./timestampheader.h','w')
f.write('/* timestampheader.h */\n')
ts = '#define BUILDTIMESTAMP "%s"\n' % time.ctime(time.time())
f.write(ts)
f.close()
print 'Time stamp definition written was:\n%s' % ts
---a generated .h file --------
/* timestampheader.h */
#define BUILDTIMESTAMP "Wed Jan 23 22:51:05 2002"
---

Use custom build options on timestampheader.h
with command (use your paths and names to suit)
    D:\python21\python .\timestampheader.py $(InputPath)
and output
    .\timestampheader.h
and dependencies
    .\testIDE.c
(which might be a long list for a big project).
The output was:
--
Hello World! on Wed Jan 23 22:51:05 2002
Press any key to continue
--

HTH,

Regards,
Bengt Richter




More information about the Python-list mailing list