Grant Jacobs wrote:
No chance you can allow the user to define a preprocessor as a command-line option, then anyone who wants to can feed the code through the C (or other) preprocessor? This could have a other uses to people who want their code preprocessed by their own means.
That's already possible, and I don't think GPC needs any particular support for it. Just let the preprocessor write its result to a temp file/pipe and let GPC read from that file/stdin(`-'). You might need `-x Pascal' (or here, perhaps, rather `-x Preprocessed-Pascal') if the temp file (or stdin obviously) does not have one of the known Pascal file name suffixes. With correctly set-up Makefiles or whatever (mostly a one-time job) it could be done quite automatically AFAICS.
It's quite the same way that program generators such as lex and yacc are usually invoked (though calling them preprocessors would be a little understatement).
Reminds me I wrote a Pascal preprocessor. Forget why, though! (I'm thinking in part here that although I can currently do push a single source file though the preprocessor, to compile a whole project like by first preprocessing it, I'd have to compile everything to .o files, then link them as I won't have access to pulling in things via 'uses' the way the Pascal compiler does. It'd be better for the compiler to feed each source code through my choice of pre-processor on my behalf. Follow my meaning?)
OK, then it would be job for the `gp' utility which is going to replace automake. Since I've yet to add user configuration to gp, this might be a point to consider. (In fact, I've thought about something like that WRT to lex and yacc, though no concrete ideas yet.)
As I'm sure you already know, one of the key uses for varargs is so that you can blindly pass on argument lists without having to consider their syntax, e.g. the arguments to printf (in C).
Sure. That's why I'm considering them at all. Currently, my plan is, when I get there, I'll see how difficult is it to implement them. If not, I'll just do it, otherwise let's see again ...
BTW, about the C syntax, what does `__VA_ARGS__' actually stand for? I'm wondering if (if we do it in the end) we shouldn't allow to define a parameter name for the varargs instead of having such an (ugly IMHO) "magic" name.
Not sure precisely, but most likely something along the lines of VARiable (number of) ARGumentS.
So `__VA_ARGS__' means `var. args. args.'!? ;-)
Frank