I had a go at writing a possible plugin API for GCC, and porting parts
of my python plugin to it:
http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=commitdiff;h=36a0d6a45473c39db550915f8419a794f2f5653e
It's very much at the "crude early prototype" stage - all I've wrapped
is part of CFG-h
David Malcolm writes:
> I initially attempted an underscore_based_naming_convention but quickly
> found it difficult to get concise function names, so I switched to a
> CamelCaseBased_NamingConvention with an underscore separating a notional
> namespace element from a secondary element, which save
David Malcolm writes:
> I had a go at writing a possible plugin API for GCC, and porting parts
> of my python plugin to it:
> http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=commitdiff;h=36a0d6a45473c39db550915f8419a794f2f5653e
Seems like a good start.
> I initially attempted an unde
Hi,
David Malcolm skribis:
> How do other plugin authors feel about the API?
I think this approach would lead to a duplication of each GCC API.
The needs of plug-ins cannot be anticipated; artificially restricting
what plug-ins can do is likely to hinder wider extension of GCC.
As an example,
On Fri, Mar 30, 2012 at 10:23 AM, Ludovic Courtès
wrote:
> Hi,
>
> David Malcolm skribis:
>
>> How do other plugin authors feel about the API?
>
> I think this approach would lead to a duplication of each GCC API.
I would call it an abstraction of GCC internals (disclaimer: I did not look
at the
Hi
Le 30 mars 2012 à 06:18, Ian Lance Taylor a écrit :
> I would recommend grouping functions by category, and making each
> category be a struct with a set of function pointers. That will give
> you a namespace, and will greatly reduce the number of external names in
> the API.
>
> Ian
Using
On Fri, Mar 30, 2012 at 10:23:16AM +0200, Ludovic Courtès wrote:
> Hi,
>
> David Malcolm skribis:
>
> > How do other plugin authors feel about the API?
>
> I think this approach would lead to a duplication of each GCC API.
>
> The needs of plug-ins cannot be anticipated; artificially restricti
Hi Richard,
Richard Guenther skribis:
> On Fri, Mar 30, 2012 at 10:23 AM, Ludovic Courtès
[...]
>> The needs of plug-ins cannot be anticipated; artificially restricting
>> what plug-ins can do is likely to hinder wider extension of GCC.
>
> Extension of GCC should happen within the GCC codebas
On Fri, Mar 30, 2012 at 3:23 AM, Ludovic Courtès
wrote:
> What about sticking to the current “API” instead, and explicitly marking
> as internal those parts that core developers know are still in flux?
A guarantee of perpetual discussions of the same topic, over and over.
(meh, GCC-x.y.z just br
On Fri, Mar 30, 2012 at 4:33 AM, Basile Starynkevitch
wrote:
> I entirely agree with the above statements. More generally, we cannot
> predict what plugins will be written for GCC, and what part of the API they
> will use, and for what purposes they will be written.
I believe somethings is being
On Fri, Mar 30, 2012 at 1:54 PM, Gabriel Dos Reis
wrote:
> On Fri, Mar 30, 2012 at 3:23 AM, Ludovic Courtès
> wrote:
>
>> What about sticking to the current “API” instead, and explicitly marking
>> as internal those parts that core developers know are still in flux?
>
> A guarantee of perpetual d
On Fri, Mar 30, 2012 at 4:45 AM, Ludovic Courtès
wrote:
> I find it important to help such unanticipated uses of GCC spread.
It is hard to design for things you do not know. How about starting
with things you do know? A possible path to progress on this issue, no?
-- Gaby
On Fri, Mar 30, 2012 at 6:59 AM, Richard Guenther
wrote:
> On Fri, Mar 30, 2012 at 1:54 PM, Gabriel Dos Reis
> wrote:
>> On Fri, Mar 30, 2012 at 3:23 AM, Ludovic Courtès
>> wrote:
>>
>>> What about sticking to the current “API” instead, and explicitly marking
>>> as internal those parts that cor
On Thu, Mar 29, 2012 at 10:58 PM, David Malcolm wrote:
> I had a go at writing a possible plugin API for GCC, and porting parts
> of my python plugin to it:
> http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=commitdiff;h=36a0d6a45473c39db550915f8419a794f2f5653e
>
> It's very much at the
On Fri, Mar 30, 2012 at 02:14:31PM +0200, Richard Guenther wrote:
>
> Btw, how ugly is it to make this API grokable by swig? Would that serve
> the python plugin?
An alternative would be to have either some easily parsable API definition
(wwhich might be sort-of offered by Swig, but I'll bet th
Romain Geissler writes:
> Using structs with some sets of function pointers may break compatibility
> between minor release.
Yes, but fortunately we have a good understanding of how not to do that.
We could also go the even safer route used for linker plugins, in which
the plugin is invoked wit
Gabriel Dos Reis skribis:
> On Fri, Mar 30, 2012 at 4:45 AM, Ludovic Courtès
> wrote:
>
>> I find it important to help such unanticipated uses of GCC spread.
>
> It is hard to design for things you do not know.
Indeed, that’s the whole point. Offer a ten-function stable API and
watch “plug-in
ludovic.cour...@inria.fr (Ludovic Courtès) writes:
> What about sticking to the current “API” instead, and explicitly marking
> as internal those parts that core developers know are still in flux?
>
> For instance, I would expect a large subset of and
> to be stable (it’s been the case in my exp
Ian Lance Taylor skribis:
> We do not want plugins to constrain internal development. So if we
> adopted your approach, the only honest option would be to mark
> everything as internal. And that would leave us where we are today.
My (limited) experience suggests that things aren’t that bad bet
On Fri, Mar 30, 2012 at 9:48 AM, Ludovic Courtès
wrote:
> Ian Lance Taylor skribis:
>
>> We do not want plugins to constrain internal development. So if we
>> adopted your approach, the only honest option would be to mark
>> everything as internal. And that would leave us where we are today.
>
Le 30 mars 2012 à 15:48, Ian Lance Taylor a écrit :
> Romain Geissler writes:
>
>> Using structs with some sets of function pointers may break compatibility
>> between minor release.
>
> Yes, but fortunately we have a good understanding of how not to do that.
>
> We could also go the even safe
On Fri, 2012-03-30 at 09:05 +0900, Miles Bader wrote:
> David Malcolm writes:
> > I initially attempted an underscore_based_naming_convention but quickly
> > found it difficult to get concise function names, so I switched to a
> > CamelCaseBased_NamingConvention with an underscore separating a not
On Fri, 2012-03-30 at 14:14 +0200, Richard Guenther wrote:
> On Thu, Mar 29, 2012 at 10:58 PM, David Malcolm wrote:
> > I had a go at writing a possible plugin API for GCC, and porting parts
> > of my python plugin to it:
> > http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=commitdiff;h=
On Fri, 2012-03-30 at 15:08 +0200, Basile Starynkevitch wrote:
> On Fri, Mar 30, 2012 at 02:14:31PM +0200, Richard Guenther wrote:
> >
> > Btw, how ugly is it to make this API grokable by swig? Would that serve
> > the python plugin?
>
>
> An alternative would be to have either some easily pars
On Fri, Mar 30, 2012 at 7:45 PM, David Malcolm wrote:
> Here's another proposal then: actually use GObject introspection -
> provide a GObject-based API to GCC.
>
> In this approach, GCC would gain a dependency on glib and gobject, and
> expose its API via a .gir file.
I greatly prefer the other
Hi
Le 31 mars 2012 à 02:45, David Malcolm a écrit :
> Here's another proposal then: actually use GObject introspection -
> provide a GObject-based API to GCC.
>
> In this approach, GCC would gain a dependency on glib and gobject, and
> expose its API via a .gir file.
I don't think adding huge d
Hi,
On Fri, 30 Mar 2012, Gabriel Dos Reis wrote:
> On Fri, Mar 30, 2012 at 7:45 PM, David Malcolm wrote:
>
> > Here's another proposal then: actually use GObject introspection -
> > provide a GObject-based API to GCC.
> >
> > In this approach, GCC would gain a dependency on glib and gobject, an
27 matches
Mail list logo
