On 13/10/10 12:04, Ian Lance Taylor wrote:
Kingsley Turner<kingsley.turner@xxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
I have a problem where if I call GCC from my python script some of the
#defines are not processed in the output. However if I paste the
exact same command into a shell, I get a correct output.
There pretty much has to be some difference in the command invocation.
I'm fairly sure the command is OK, since I log the command before passing it
to the python subprocess.popen(). This is then the command I paste into the
interactive shell.
What do you mean when you say that some #defines are not processed? Can
you show a small example?
In the output-file:
// # 1 "/tmp/dd-compile_1286932120.73/menuefmg6021hart.dd" 1
// # 1 "/tmp/dd-compile_1286932120.73/menuetextsfmg6021.h" 1
// # 2 "/tmp/dd-compile_1286932120.73/menuefmg6021hart.dd" 2
// # 10 "/tmp/dd-compile_1286932120.73/menuefmg6021hart.dd"
...
// # 29 "/tmp/dd-compile_1286932120.73/menuefmg6021hart.dd"
MENU BASIC_SETUP_M
{
LABEL basic_setup
ITEMS
{
But if we examine one of the included files "menuetextsfmg6021.h", we see
the #define that doesn't seem to be working:
menuetextsfmg6021.h:
...
#define basic_setup "|de|Grundabgleich|en|basic setup|fr|Etalonnage
base|it|Calibrazione base";
...
So the GCC output says the include file was included, but the definition of
'basic_setup' was not used. The include file contains nothing except a
dozen #defines, so it was not excluded because of a #if/#ifdef switch.
The preprocessor does pay attention to a few environment variables, as
documented at
http://gcc.gnu.org/onlinedocs/gcc-4.5.1/gcc/Environment-Variables.html
Thanks for the tip, I'll check all these now.
Makes me wonder if I am passing the environment through to the sub-shell
properly!?
cheers,
-kt
