"Dimitrie O. Paun" wrote:
> > Anyway, I have do some experimentation and I found out that
> > this simple patch implements a pre wrc call to the C preprocessor.
> > Works with both Solaris C/CPP and GNU C/CPP.
>
> That's good news -- let's use that then and make wrc smaller, and faster.
> Bertho, do you see any problems with that?
Well, a good question. Stripping the preprocessor could be an advantage
if it was solely used with wine. But, this is not the case. There have
been other uses of wrc which require the preprocessor built in.
--
To make it short [ahum;-];
I intended wrc to be versatile enough to be used both within wine
(because we lacked a real resource-compiler back then) and powerfull
enough to be used within other projects which have nothing to do with
wine, but want to use windows-resources (for whatever reason). The
wine-licence made this a perfect option and I kinda liked it too.
So, keeping that in mind, the whole discussion is a bit artificial and
not changing my work nor my attitude in putting a real preprocessor into
wrc's frontend. This will be entirely optional for use and a
command-line option can be used to bypass it.
Even if Alexandre would want to reject the upcoming patches (which I do
not think he will), then it would still not change my attitude because
the changes will be published by other means. Solely because I feel that
wrc should be capable of compiling resources in a stand-alone manner and
no one should be required more than wrc to get resources compiled.
--
Back to the above question. Yes, wrc will be faster. That is actually
the primary technical reason for me to split wrc into a
preprocessor/compiler combination. The current mix (a bad hack) was
there to help out for the time being. The extra rules in the scanner and
parser make it awfully complex to change anything of substance in any
part. This is why user-resources and filenames are wrong. I could not
get this put into the current design without making an even worse hack.
Wrc's backend will be cleaned up so it will understand enough C and C++
constructs so that they can be filtered out and for the rest it will be
a 'clean' and 'compatible' compiler. All lexical substitutions (i.e. the
preprocessor) will be done in the frontend. Whether you choose to use it
is not my primary concern.
Then for reinventing the wheel. Yes, many have done it before. But, do
you know a full-working preprocessor in the public domain that can be
put into wrc without problems? I don't. The rest I know is GPL.
I hope this will explain some of the work being done.
Greetings Bertho
