Re: plugin directory

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Rafael Espindola wrote:
> Sorry for takes this long.
> 
> I am not convinced that putting this bit of policy into gcc is good.

  I don't think you need to worry so much about it.  The bit of policy
effectively already _is_ present in GCC, else how would
"-print-file-name=plugin" work?  The semantics of that are all clearly
defined, aren't they?

  It really seems to me like the patch just reuses something that already
exists inside GCC by optionally presenting it in a convenient-to-use way for
the end user.  It is a nice and user-friendly bit of interface design as far
as I can see.  Do you envisage some kind of a problem arising in the future if
we adopt this mode of usage?  Please, can you reconsider a bit whether this is
really such a bad idea?

> Basile STARYNKEVITCH wrote:

> I do believe that
>    gcc -fplugin=treehydra
> is a more appealing way to use the treehydra plugin than some more
> complex, distribution or installation specific, way to do that.

  I do too, very much so.  Beginners will love it.  Oh, will nobody think of
the noobs?  ;-)

  Basile, one thought did occur to me: rather than hardcoding the ".so"
extension in add_new_plugin(), can you get the necessary information (maybe
from libtool?) during the build?  I'm guessing the 'libexec' part of the
subdir path isn't autoconf-able so is no problem to hardcode, but since you
can't specify an extension on the short form of --plugin=, it might be better
to compute it rather than hardcode it, or perhaps just to allow the user to
specify an extension even in the short form.

    cheers,
      DaveK