I have two files fsm_right.c and fsm_left.c
in my main program, before any other header files, I have this
#define FSM 1
#ifdef FSM #ifdef FMSLEFT // note: currently undefined include "fsm_left.c" #else include "fsm_right.c" #endif #endif
the next line is
unsigned char author= "whatever";
The compiler spits up on the assignment line, with a C129 missing ';' before <string>
So I figured, something in fsm_right was incorrect. To test this, I commented out the include "fsm_right.c" (and this same thing happens with the <fsm_right.c> syntax. The program compiles without a problem. So I figured the problem was in fsm_right.c I edited fms_right.c and deleted EVERYTHING in it, so it is just a blank file.
And it *STILL* has the error. This is version 7.5 by the way. K&RC say that the include statement is replaced by the contents of the file.
What in the world is going on here? With the include commented out //include ..... it compiles fine. With the include NOT commented out, it gives the error WHETHER OR NOT there is anything in the body of the included file.
This makes no sense. Is there a bug in the pre-processor? environment is windows XP running Silabs IDE with the Keil 7.5 as the compiler. I've seen this before, could not figure it out and went a different direction, but now I need to have it this way.
The project consists of a main file, and a second C file with some constants and structures. I compile them seperately and link them. Now I need to build two new configurations, to be controlled by compile time switches. I don't want to put fsm_left and fsm_right into the structure file, because then I would have to set the define in that file, as well as the main file, and this can result in building the wrong device. The main file compiles code for 3 seperate products based on compile time switches. The 3 devices share a common set of structures, though not all of them are used by each build.
I don't want to have to correlate #ifdefs between files, And I'm telling you that that's really not a good plan. There's nothing to be afraid of in #defining switches in a central file or project build configuration. Particularly for #defines used to distinguish between different build targets of the same source tree, like you're dealing with here, it's basically the only sane way of doing it. The build target selection is about as global a switch as they come. Trying to limit it to one of multiple source files won't solve any problems ... it'll only create new ones.
So I was attempting to build a selective include based on defines, and it is just not working. You're a couple steps removed yet from establishing that.
in code that does not have an error, that in fact has been building just fine. That conclusion is generally premature. Building fine is a necessary condition for having no errors, but far from being a sufficient one.
IDE make file switches are out of the question. I have to many to manage that way.
I'll have to call BS on that one. How can it possibly be too hard to manage the measly 6 switches (or even just one, if you go at it a bit less naively) that it really takes to differentiate 6 targets, just because they're in the IDE?
Not only is the IDE better at managing those compiler switches than you'll ever be editing them inside a single module (because it would keep all 6 configurations permanently), it would also entirely remove the need for what you came here for originally. Instead of #including one of several source files into another, the IDE would let you disable building all but one of them, just by ticking boxes.
So I was attempting to build a selective include based on defines, and it is just not working.
You're a couple steps removed yet from establishing that.
I'd suggest you try a simple test for your self. Take the #define code I posted, and insert it in the front of a C file after the normal includes. Create an empty fsm_left.c and an empty fsm_right.c Follow it with some valid C code, and see if it doesn't throw a C129. Then put in a couple lines of code into the files and try it again.
in code that does not have an error, that in fact has been building just fine. That conclusion is generally premature.
All code except the most trivial, has errors, and even then sometimes simple code has errors. This error is however, a new build error, included by something that should be a valid C construct. This code has been building fine, and running in the field for years. There are no build errors in the build until you attempt to include a C file within a conditional define, and then bingo. This error occurs. I've seen it numerous times in the C51 compiler over the years, and it has been a headache to code around.
Building fine is a necessary condition for having no errors, but far from being a sufficient one.
Adding multiple builds with ide switches is problematic in the silabs ide. It only allows one build configuration per project.