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