is this possible

You know that CodeWright can hide code that's inactivated by #if...?

You know that CodeWright can hide code that's inactivated by #if...?

You know that CodeWright can hide code that's inactivated by #if...?

I do, but never figured out how to make it work when the file with #define TYPEA is in the same subdirectory as the file with #define TYPEB and neither #defines are in the file being looked at.

Erik

How about something like:

#if ATYPE
#define ATYPE
#define BTYPE  if (0)
#define CTYPE  if (0)
#endif


ATYPE
    {
    code;
    goes;
    here;
    }

BTYPE
    {
    other;
    code;
    here;
    }

CTYPE
    {
    less;
    code;
    }

The optimizer should take out the dead code. The brackets help make it very clear where the extent of the variant code lies. You can also nest blocks inside of them without worries about comment styles.

what the optimizer does is irrelevant, that works just fine with #define. The issue is to find a means that, at the beinning of each line, identify the type when looking at it in CodeWright.

so, instead of
#ifdef TYPEA
aline1
aline2
aline3
...
#endif
#ifdef TYPEB
bline1
bline2
bline3
....
#endif

it would look like this
TYPEA aline1
TYPEA aline2
TYPEA aline3
....
TYPEB bline1
TYPEB bline2
TYPEB bline3
....

just dreaming, I know, but sometimes a dream can come true :)

Erik

what the optimizer does is irrelevant, that works just fine with #define. The issue is to find a means that, at the beinning of each line, identify the type when looking at it in CodeWright.

If you do it the way you want, you'll confuse CodeWright no end --- it'll lose track of the C syntax of your code. You'll basically lose most of the advantage a programmers' editor has over Notepad.

You may want to reconsider whether you really have to edit the same file that the compiler will get to see. The C preprocessor is not the be-all and end-all of on-the-fly source code manipulation. You could preprocess a single ".cin" file with Perl or similar tools to generate multiple .c files and feed only those to the compiler.

and feed only those to the compiler.

The problem is when I look at the code in the editor, it is almost never clear which group of code I am looking at.

My code generate 47 different builds and maintaining them as separate 'projects' would never work (a fix to the common code implemented in 46 and missed in one)

The problem is when I look at the code in the editor, it is almost never clear which group of code I am looking at.

That much was clear from the beginning.

You don't seem to grasp what I'm suggesting, though. My proposal is to avoid this gotcha by not having the actual C code to look at. And the method of doing that is to provide C source only while it's being fed to the compiler: create a C file for variant A from the common, not-quite-C code file, compile it, and if the compile went well, delete the temp file. Then do the same for variant B.

The benefit is that instead of C preprocessor macros, you can use whatever syntax you like to indicate what platform any file is for, as long as you have a tool that can translate it to C. You could even actually have your "combined C file" look like your original idea. A simple little 'sed' script could decode that. In pseudo-shell syntax:

sed -e '/^TYPE[^A]/d' module.cin' | c51

You don't seem to grasp what I'm suggesting, though. My proposal is to avoid this gotcha by not having the actual C code to look at. And the method of doing that is to provide C source only while it's being fed to the compiler: create a C file for variant A from the common, not-quite-C code file, compile it, and if the compile went well, delete the temp file. Then do the same for variant B through m.

That process is waaaaay to likely to miss one variant, I have, believe me, tried it and failed.

To do so, you have to rely on the so called "testing" and that would be a true disater.

The suggestion, although dismissed, is still appreacited, Thanks

Erik

The same would seem to be true with a C-preprocessor-based solution. You still have to compile versions A, B, and C, even to make sure that the syntax is correct given the three #defines. Since you have three images, you really need to test all three to be certain that they all work. You might be able to use knowledge of the variant areas of the code to limit the scope of the variant testing.

But whether you use m4 or the preprocessor or an array of little gnomes to alter a text file, you have three different inputs to the compiler proper.

the problem with "after preprocesor/after compile/after ..."s that you do not "see what you want to modify" (the common source) just "see where you want to modify" which is OK (to some extent) when only one of the variants is to be possible, the problem is that you do not - initially - know if what you are looking for is in a variant of something common. So, according to Murphy, you will use the "after" method and find soemthing you want to see "before" and, again according to Murphy, you will use the "before" method and find soemthing you want to see "after". Oh well, just a faint hope.

Thanks to all,

Erik