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

["Peter A. Buhr" <pabuhr at plg2 dot math dot uwaterloo dot ca>]

   From: Zack Weinberg <zack@codesourcery.com>

   It would be most helpful to this discussion if you could lay out what
   it is that your software _does_.  I'm fairly confident there is a good
   way to make GCC do what you need it to do.  It's just that I suspect
   what you are asking for is not what you actually need.

Our software converts C++ from a sequential programming language into a
concurrent one. It is not a "pthreads" package with threads and locks; it
integrates concurrency into the object-oriented paradigm of C++, supplying
coroutines, monitors, coroutine-monitors, and tasks. It also includes real-time
support and a full non-blocking I/O library. I think it blows the doors off
what's in Java.  Detailed information is available at:

   http://plg.uwaterloo.ca/~usystem/uC++.html
   http://www.student.math.uwaterloo.ca/~cs342

It's all freeware and you can ftp the source and take it for a test drive.

Because we have added new kinds of classes and statements to C++, we have to
parse the program to find the new language features and convert them to C++. We
must see the program *after* expansion by cpp otherwise new language features
could be missed because they are expanded via #define or are in include
files. The conversion to C++ is complex, requiring parsing significant parts of
the program and generating a partial symbol table. That is, the conversion
cannot be done by simple textual substitution. Ultimately, we would like to
extend C++ with the features we have designed, but that must wait for another
day with the ANSI C++ committee.

   > I'm fairly confident there is a good way to make GCC do what you need it
   > to do.  It's just that I suspect what you are asking for is not what you
   > actually need.

Trust me, I know my needs. 8-) I've been working on gnu software and gcc for
20+ years, and on the concurrency project for 10+ years. If there were simpler,
better ways, I'd probably be doing that. Having said that, I'm always open to
new ideas, as no one knows everything. So I'm always happy to be shown methods
of work that make solving my problems easier.

   > For instance, cpplib could easily be modified to permit insertion of a
   > user-supplied filter routine between itself and the C/C++ parser. It's
   > quite possible that you could rewrite your program to use such a
   > filter instead of operating on the textual preprocessor output.
   > (You'd be linking your code into GCC, so it would have to be GPLed,
   > which may or may not be a show-stopper for you.)

Let me break this discuss into two streams, and I'll make it up as I go. ;-)

1. Zack is suggesting a user-filter for the builtin cpp. As Neil, points out
   this is a yes and no solution. If the filter is compiled into gcc/g++, it
   would still be useful but only for situations where people are willing to
   change the compiler on their system. Many people cannot or will not do
   this. Also, different software packages may each have their own filters, so
   either multiple filters are impossible or a switch is needed to select from
   the set of compiled in filters.  Alternatively, the builtin cpp could look
   in the -B directory for user-filters. Some naming convention could be used,
   such as "pre-cpp" and/or "post-cpp", and the builtin cpp would call the
   pre-filter before expansion and the post-filter after expansion. It might be
   possible to extend this to multiple pre/post filters and use a simple number
   in the filer name to define the ordering filters are invoked.  In essence,
   this latter scheme is very similar to the existing -B with cpp.  However,
   there is an additional problem of getting filter specific flags from the
   command line to the filters.

   I believe this scheme could be made to work but I think it would take some
   time and design to get it correct and fit into the compiler.

2. What I'm suggesting is a less radical solution, that is already well tested
   because it's been there since day one, and seems to fit in for the
   short-term while final issues related to the integrated cpp are resolved.
   What I fear is waking up tomorrow morning and finding that RedHat 7.3 is
   released with gcc-3.x as the default or only compiler, and my software is
   now a dead duck. I have only looked at gcc-3.0.2, so I can't speak for the
   snap-shot you are working on.  But the changes we suggest for gcc-3.0.2 are
   very minimal (assuming we can find a name for the flag), and could be vetted
   by someone at your end in a few hours. If there are problems, we are happy
   to make changes to our patch and/or do further testing, until you are
   happy. Furthermore, we are also happy to work with you to find an
   alternative solution for the future. But let's not forget about the present!

Finally, can anyone give me a sense if I'm talking to the right people about
this problem? Neil/Zack do you have authority/control over the gcc driver?  Can
you authorize the change we are suggesting? Is there someone else I should be
talking to? I'd really like to make progress on this issue as soon as possible.

Thanks for listening to this problem.