Re: Report: using GCC plugin to implement ORM for C++

[Manuel López-Ibáñez <lopezibanez at gmail dot com>]

On 30 September 2010 12:26, Boris Kolpackov <boris@codesynthesis.com> wrote:
>
> What didn't work so well:
>
> ?- The plugin header inclusion is a mess. You have to include the right
> ? ?set of headers in the right order to get things to compile. Plus, the
> ? ?GCC headers poison some declarations, so, for example, you cannot use
> ? ?std::abort. Maybe there is a good reason for this.

There is a good reason within GCC but I think no good reason outside
of it. If you want to make your life easier in the future, you should
really contribute patches that move those poisons to some internal
header not required by plugins, like, poison.h or something like that.

The fact that the plugin header inclusion is a mess is because GCC
headers are a mess. Any little step separating internal stuff from
external interface will benefit both plugins and the modularity of
GCC. GCC developers don't work on this often because it is not an
issue for them, but plugin developers (like you) should push by
providing patches that make this separation clearer.

> ?- If the plugin needs to generate something other than assembly (C++
> ? ?in our case), then the code that suppresses the opening of the
> ? ?assembly file is quite hackish.

Open a PR and/or provide patches. GCC devs have said that they want a
more modular GCC, and will accept patches to make this happen.

> ?- There is no callback point after the tree has been constructed and
> ? ?before any other transformations have been performed. We use the
> ? ?first gate callback (PLUGIN_OVERRIDE_GATE) and do all our work
> ? ?there. There is also no well-defined way to stop the compilation
> ? ?process at this point. We simply use exit().

Everybody would be better off if you proposed changes to make this work

> ?- Working with the GCC tree is not for the faint of heart. Generating
> ? ?code from it is particularly hard. In fact, we have created our own
> ? ?C++ classes (called "semantics graph") to represent the translation
> ? ?unit being compiled. It is not as complete as the GCC's tree but it
> ? ?is a lot easier to traverse.

Without knowing which problems you have that cannot be solved with
GCC's representation is a bit difficult to say whether GCC's
representation could be improved or whether that semantic graph is
something that GCC could build itself.

> The ODB compiler uses the GCC compiler frontend for C++ parsing and is
> implemented using the new GCC plugin architecture. While ODB uses GCC
> internally, its output is standard C++ which means that you can use
> any C++ compiler to build your application.

Maybe mention your plugin in the table at http://gcc.gnu.org/wiki/plugins  ?

Cheers,

Manuel.