Hi,

Richard Guenther <richard.guent...@gmail.com> skribis:

> But no, I'm not volunteering (I'm volunteering to do the review work).
> The above has the same issue as the "we-want-to-be-more-like-LLVM"
> stuff - it lacks the people to actually implement it, and GCC at its
> present state still has to evolve, we can't and do not want to just spend
> a complete release or two with just turning GCC upside-down.

What David proposes looks great, but also fairly intrusive and
development-intensive.

Perhaps a more incremental approach could be taken.  For instance, I
would argue that changes to the tree and GIMPLE APIs could be made
conservatively, on the grounds that they are most likely used by
plug-ins out there.  IOW, rather than a commitment to a stable API,
which would hinder the work of GCC developers, this would be an informal
agreement to not make the plug-in developers life too hard.

In the example of name mangling, I’d just have wrapped in ‘extern "C"’
all the headers listed in ‘PLUGIN_HEADERS’ in gcc/Makefile.in.  The
rationale is that it simplifies plug-in maintenance, while not impeding
development work in 4.7.

In the longer term, providing a GCC plug-in alongside one’s library or
program should become as natural as providing a syntax highlighting mode.

Thanks,
Ludo’.

Reply via email to