This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Changes to gcc 3.x to invoke an external cpp


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]