This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Changes to gcc 3.x to invoke an external cpp
- From: "Peter A. Buhr" <pabuhr at plg2 dot math dot uwaterloo dot ca>
- To: neil at daikokuya dot demon dot co dot uk
- Cc: asharji at plg2 dot math dot uwaterloo dot ca, gcc-patches at gcc dot gnu dot org
- Date: Tue, 4 Dec 2001 20:15:45 -0500 (EST)
- Subject: Re: Changes to gcc 3.x to invoke an external cpp
- References: <Pine.SOL.3.96.1011130134521.152B-100000@plg2.math.uwaterloo.ca> <Pine.SOL.3.96.1011130173708.10036A-100000@plg2.math.uwaterloo.ca> <20011130231509.C15578@daikokuya.demon.co.uk> <200112030257.VAA16142@plg2.math.uwaterloo.ca> <20011203075049.A8874@daikokuya.demon.co.uk>
I'm sorry for the delay in responding. It's a very busy time of year.
Why can you not use -E to get the preprocessed output, do what you want
with it, and then invoke g++ with -fpreprocessed?
Let me answer this by sketching out the two scenarios, i.e., the current one
where we use -B with a user defined cpp and your scenario. But let me set the
stage by looking at a complex command line invoking gcc/g++:
% g++ A.cc B.C C.cpp D.o E.s -D... -f... -W... debugger & linker flags
1. We start with a command called "u++", which is used instead of g++. u++ does
a quick scan through the argv list looking for "special" flags appropriate
to our software. This scan is very simple and would probably fail if someone
used a file name in certain contexts that is the same as one of our flags,
but it's good enough for us (in 10 years there has not been a problem).
Based on these special flags (which are removed) we add a few -D... flags, a
-B/dir-name and some extra libraries to the command arguments. Finally, we
do an execvp on g++ with the modified argument list. The entire u++ command
is about 400 lines of code with some error checking.
Then g++ kicks in and parses that entire command line. Parsing that command
line is very complex (2000-3000 lines of tricky code). Each source file has
to be found (there are 6 different suffixes denoting C++ source files), and
for each source file the preprocessor has to be invoked with *just* the
command line flags pertaining to it (about 25+ possible flags). Because of
our -B flag our "cpp" is called with just the right flags and files. Our cpp
creates a temporary file, calls cpp with the given flags and the temp file
for output, then it calls our translator on the expanded code in the temp
file to finish the source transformation, where the output is written into
the destination file given to our cpp. And Bob's Your Uncle! This process is
then repeated by the gcc driver for each appropriate source file that must
be preprocessed and all the pieces are finally put together by the driver to
form an a.out. Told size of our cpp is about 200 lines of code.
2. Now since I have not done your approach, I have to guess a bit here, but I
think my outline is close. In your scenario, my u++ command has to parse the
complete command line to locate the source files and the preprocessor flags.
And for each source file, invoke "gcc -E" with any preprocessor flags from
the comand line putting the output into a temp file (temp.ii), and then
invoke my translator on the temp file, and then invoke gcc with the temp
file. However, I can't do that because I have to put all the pieces
together to form a single a.out, so I have to create all the temp files and
pass all the temp files in one call to gcc to do the final compile. In
addition, there may be subtle interactins among flags that have to be
checked for and dealt with appropriately, e.g., -E and -save-temps, etc. I
estimate this will take about 3000+ lines of complex code, of which 95% is
largely a duplication of what's in the current gcc driver. Furthermore, if
new flags are added or removed from gcc, I have to correspondingly update my
u++ command to add or remove these. Which means I have to spend many hours
keeping my u++ command consistent. All of this augurs against this approach.
So this is the reason why I want the --user-cpp (-zzzz-cpp) flag, because I
believe there is no viable alternative for it.
If it helps, the software we produce is freeware.