Defining a common plugin machinery

Taras taras.judge@shaw.ca
Sat Sep 20 00:48:00 GMT 2008


Brendon Costa wrote:
> Joseph S. Myers wrote:
>   
>> I think this is a bad idea on grounds of predictability.  
>>     
> I can understand this view and was initially reluctant to suggest the
> auto-load feature for this same reason. However i can not see another
> solution that can be used instead of this to achieve simple usability
> for a small subset of plugin types (described below).
>
>   
>> Separately developed plugins have many uses for doing things specific to 
>> particular projects 
>>     
> This is the case for the Dehydra, which is specific to the Mozilla
> projects. However the plugin i would like to develop it is NOT designed
> to be used with a specific project, but to be used while compiling any
> project.
>   
Sorry to nitpick, but there is nothing Mozilla-specific in 
dehydra/treehydra. There are users outside of Mozilla.
However, I do think it's awesome to be able to store plugin results in 
the resulting binary to do LTO-style analyses. How well is that working 
for you?

Taras



More information about the Gcc mailing list