Russ Whitaker wrote:
On Fri, 13 Apr 2001, Frank Heckenbach wrote:
Russ Whitaker wrote:
Since CPP is in use elsewhere,
Err, where?
CPP_SPEC (6 PLACES) CPP_PREDEFINES USE_CPPLIB
Macro substitution occurs only on whole tokens, not on parts of identifiers, so that's no problem.
The only place I see it is in some shell scripts which are completely unrelated. (In fact, any use in a file not included by gpc.c would be unrelated.) Though, of course, renaming it to anything else (which doesn't conflict with anything) should work just as well.
renamed cpp to czz in the table. then added:
Do you mean CPP or "cpp" (besides C's case-sentivity, the real question is whether you renamed the CPP macro I introduced, or the cpp as part of the quoted strings)?
I maintain that gpc.c in 20010409 is messed up, so copied over a virgin copy of gpc.c from 20010317 and worked with that. Thus the renaming and the following snipet was a cautious approach that paid off when it did't work.
#ifdef GPC_2_95_3 #define czz cpp0 #else #define czz cpp #endif
Compiled ok, but the test suite bombed out with czz. Obviously, define should have replaced czz with either cpp0 or cpp but did neither.
Well, I don't know exactly what you did. It seems you renamed cpp in the quoted string. This will not work, since (as you said correctly) defines are not replaced in quoted strings.
But where I use the CPP macro is always outside of quoted strings (Really! I just checked it again!),
Of course! gpc.c in 20010409 is wrong!
so if you renamed the macro to czz, there's no way it can creep into the gpc executable (you can check with `strings' or `grep'), so gpc won't try to call czz. Maybe you did something wrong, or your files have become inconsistent with our sources due to your previous attempts to solve the problem.
gpc parses lines in the table to determine what sub-programs to call and what parameters to pass. Since czz did't get replaced and there was no czz in the bin directory ...
I suggest you get a fresh copy from CVS, move the define below the includes (if this change isn't in the CVS yet -- I'm not sure at the moment), then it should work without any renaming...
I think I'll wait for the smoke to clear.
Well, let me say this again:
- 20010409 is broken, but only because the define is before, not after the includes. The name of the define (CPP) and the way it's used (outside of quoted strings) seems to be correct. Simply moving the define after the includes should work (patch below; this will also be in the next GPC version). Why don't you just try it?
- I really don't know what you did with czz, but if the string czz did creep into the table in the executable, you probably have inserted it within a quoted string or something (unlike my CPP macro). If you send me your file with these changes, I can perhaps find out what the problem is ...
--- gpc.c.orig Fri Apr 13 10:23:04 2001 +++ gpc.c Fri Apr 13 00:29:17 2001 @@ -38,14 +38,6 @@ * This file is derived from GCC's `gcc.c'. */ -#ifdef GCC_2_95_3 -/* gcc "wants this on by default all the time now" (cf. gcc.c) */ -#define MKTEMP_EACH_FILE -#define CPP "cpp0" -#else -#define CPP "cpp" -#endif - #include "gcc-version.h" #include "p/version.h" #include "config.h" @@ -73,6 +65,15 @@ #include <varargs.h> #endif #include <stdio.h> + +#ifdef GCC_2_95_3 +/* gcc "wants this on by default all the time now" (cf. gcc.c) */ +#undef MKTEMP_EACH_FILE +#define MKTEMP_EACH_FILE +#define CPP "cpp0" +#else +#define CPP "cpp" +#endif
#ifndef R_OK #define R_OK 4
Frank