Aye up all,
I think the env var solution is easier for people to use and
immediately understand. There would be nothing to stop those people who
don't like env vars from using the shell wrapper approach. Why not
allow both?
Are you sure about this style of event/callback mechanism? It seems
to scale poorly. Isn't it likely to be a bit inefficient, too? Through
this approach, plugins can't cooperate; they can't easily define their
own events and it feels too early to prevent that.
It looks like it's trying to replicate the abstraction of calling a
function with something worse. What I mean is that I think what people
would like to write is:
GCC side:
void fireMyEvent( 10, "hello" );
Plugin side:
void handleMyEvent( int n, const char* msg ) {
// use args
}
But now they have to write:
GCC side:
//Add to enum
enum plugin_event {
PLUGIN_MY_EVENT
}
// Create struct for args
typedef struct my_event_args {
int n;
const char* msg;
} my_event_args;
// Call it:
my_event_args args = { 10, "hello" };
plugin_callback( PLUGIN_MY_EVENT, &args };
Plugin side:
void handleMyEvent( enum plugin_event, void* data, void*
registration_data ) {
if( plugin_event == PLUGIN_MY_EVENT ) {
my_event_args* args = ( my_event_args* )data;
// Use args
}
}
Which seems a bit ugly to me. Although, it does have the advantage
of being easy to implement on the GCC side.
And, if they're replacing a heuristic and need a return value then
even more lines of code are needed on both sides. How would this style
work for replacing heuristics?
Cheers,
Hugh.
Grigori Fursin wrote:
Personally I'm against the env var idea as it would make it harder to
figure out what's going on. I think someone mentioned that the same
effect could be achieved using spec files.
Ian mentioned the idea of creating small wrapper scripts with the names:
gcc/g++ etc which just call the real gcc/g++... adding the necessary
command line args. These can then just be put earlier in the search path.
I currently use the env var method in my project, but I think the
wrapper script idea is a bit nicer than using env vars personally, so i
will likely change to that soon.
That's right. It's a nicer solution. We just already have environment variables
in our ICI implementation, but it can be useful if we will one day switch
to the common plugin system without support for env variables ...
Cheers,
Grigori
Brendon.
