[RFC] Plugins: enhancements

[RFC] Plugins: enhancements

[Keith Seitz]

Hi,

So I am revisiting the plugin architecture, which, thanks to Fernando, is
largely complete. [Thanks Fernando!]

I have some questions about some of the last problems that exist with this
code...

1) Building plugins (C/C++ code)

Right now, one cannot generically build a plugin from C code. That part of
the configury was not completed.

I believe that I have now practically isolated all the host dependencies
for all the configury to accomplish building code on both unix (Linux only
tested) and Windows (tested on cygwin, of course). Using the following
Makefile.in for rhabout, I can now successfully build and install the
loadable module "rhabout":

   PLUGIN = rhabout
   PLUGIN_OBJS = rhabout.$(OBJEXT)
   PLUGIN_IMAGE_BASE = 0x65000000
   PLUGIN_TARGETS = rhabout.itcl

   include ../Make-rules

Yep, that's all that's necessary to build "rhabout.so" and "rhabout.dll"
and install them and the corresponding tcl files in the right place. I've
changed a lot of configury to get this working, and although it's not
perfect, it is one huge step forward. (The image base thing is for Windows
dlls. I'm not convinced it's necessary, but other much more informed
people tell me it is good practice to specify this for windows, so I'm
leaving it in.)

If we ever decide to drop support for Tcl/Tk 8.0 baggage we carry, we can
then revisit this with TEA in mind.

Questions:

1) We are currently have plugins directory located in
gdb/gdbtk/library/plugins. I don't think this is the right place to put
it, since the plugins can be host-dependent, containing shared
libraries/DLLs. Instead, I'd like to move the plugins directory from
gdb/gdbtk/library/plugins to gdb/gdbtk/plugins.

2) The plugins are currently installed in
INSTALLDIR/share/insight1.0/plugins. This directory is NOT
platform-dependent, so if we install both Cygwin and linux toolchains into
the same directory (which I do quite often), the two are going to clobber
each other a little. I propose that these be moved to
$(libdir)/insight1.0/PLUGIN-NAME. The generic plugins.tcl file will be
installed at $(libdir)/insight1.0/plugins.tcl.

Comments?

All the configury for this is in gdb/configure.in. It is at least isolated
in our own little spot. I don't like this, but until we can put all of the
insight stuff under a directory in the gdb build directory, we're stuck.
(The limiting step here is being able to build separate gdb and insight
executables, which actually can be hackishly done, but gdb would never
approve of the "cp top.c gdbtk-top.c" method.)

Keith

Re: [RFC] Plugins: enhancements

[Tom Tromey]

>>>>> "Keith" == Keith Seitz <keiths@cygnus.com> writes:

Keith> Using the following Makefile.in for rhabout, I can now
Keith> successfully build and install the loadable module "rhabout":

Keith>    include ../Make-rules

This syntax for `include' isn't portable.  Automake has a macro to
check for a few different include styles.  (Note that you can't be
guaranteed that there is any include directive, but such systems
aren't worth worrying about, imnsho.)

Keith> 2) The plugins are currently installed in
Keith> INSTALLDIR/share/insight1.0/plugins.

I agree that this must be changed.  And I think your proposed spot for
it is fine.  The GNU coding standards are pretty clear on these
points.

Suppose I'm writing a third-party plugin.  How will I find this
directory to install my files?  I ask because presumably the version
number is in there anticipating that it will change someday.

One solution would be to have some kind of script that prints out the
relevant information.

Tom

Re: [RFC] Plugins: enhancements

[Keith Seitz]

On 24 Nov 2001, Tom Tromey wrote:

> >>>>> "Keith" == Keith Seitz <keiths@cygnus.com> writes:
>
> Keith> Using the following Makefile.in for rhabout, I can now
> Keith> successfully build and install the loadable module "rhabout":
>
> Keith>    include ../Make-rules
>
> This syntax for `include' isn't portable.  Automake has a macro to
> check for a few different include styles.  (Note that you can't be
> guaranteed that there is any include directive, but such systems
> aren't worth worrying about, imnsho.)

I'd love to use automake, but until I can get a clean split between gdb
and Insight's configury, I don't think this is possible. So for now, I am
stuck with using just Makefile.ins.

> Suppose I'm writing a third-party plugin.  How will I find this
> directory to install my files?  I ask because presumably the version
> number is in there anticipating that it will change someday.

Hmmm. Well, I guess there are some solutions... The third-party plugin
writer includes the copy of Make-rules which will tell it where to put it,
we can, as you say, make some sort of script to tell him where to put it,
or he can put it where ever he wants to, and then just tells Insight where
to find it.

I'm also sitting on patches to add an INSIGHT_PLUGINS environment
variable, which will be a colon-separated list of directories to search
for plugins.

Keith

Re: [RFC] Plugins: enhancements

[Tom Tromey]

>>>>> "Keith" == Keith Seitz <keiths@cygnus.com> writes:

>> This syntax for `include' isn't portable.  Automake has a macro to
>> check for a few different include styles.  (Note that you can't be
>> guaranteed that there is any include directive, but such systems
>> aren't worth worrying about, imnsho.)

Keith> I'd love to use automake, but until I can get a clean split
Keith> between gdb and Insight's configury, I don't think this is
Keith> possible. So for now, I am stuck with using just Makefile.ins.

Yeah.  But you could use the macro from automake to get the correct
`include' syntax.

Another choice would be to use configure's facility to concatenate
multiple files.  That would keep the Makefile.in small but not rely on
make-time includes.

Tom

[RFC] Plugins: enhancements

[Keith Seitz]

Hi,

So I am revisiting the plugin architecture, which, thanks to Fernando, is
largely complete. [Thanks Fernando!]

I have some questions about some of the last problems that exist with this
code...

1) Building plugins (C/C++ code)

Right now, one cannot generically build a plugin from C code. That part of
the configury was not completed.

I believe that I have now practically isolated all the host dependencies
for all the configury to accomplish building code on both unix (Linux only
tested) and Windows (tested on cygwin, of course). Using the following
Makefile.in for rhabout, I can now successfully build and install the
loadable module "rhabout":

   PLUGIN = rhabout
   PLUGIN_OBJS = rhabout.$(OBJEXT)
   PLUGIN_IMAGE_BASE = 0x65000000
   PLUGIN_TARGETS = rhabout.itcl

   include ../Make-rules

Yep, that's all that's necessary to build "rhabout.so" and "rhabout.dll"
and install them and the corresponding tcl files in the right place. I've
changed a lot of configury to get this working, and although it's not
perfect, it is one huge step forward. (The image base thing is for Windows
dlls. I'm not convinced it's necessary, but other much more informed
people tell me it is good practice to specify this for windows, so I'm
leaving it in.)

If we ever decide to drop support for Tcl/Tk 8.0 baggage we carry, we can
then revisit this with TEA in mind.

Questions:

1) We are currently have plugins directory located in
gdb/gdbtk/library/plugins. I don't think this is the right place to put
it, since the plugins can be host-dependent, containing shared
libraries/DLLs. Instead, I'd like to move the plugins directory from
gdb/gdbtk/library/plugins to gdb/gdbtk/plugins.

2) The plugins are currently installed in
INSTALLDIR/share/insight1.0/plugins. This directory is NOT
platform-dependent, so if we install both Cygwin and linux toolchains into
the same directory (which I do quite often), the two are going to clobber
each other a little. I propose that these be moved to
$(libdir)/insight1.0/PLUGIN-NAME. The generic plugins.tcl file will be
installed at $(libdir)/insight1.0/plugins.tcl.

Comments?

All the configury for this is in gdb/configure.in. It is at least isolated
in our own little spot. I don't like this, but until we can put all of the
insight stuff under a directory in the gdb build directory, we're stuck.
(The limiting step here is being able to build separate gdb and insight
executables, which actually can be hackishly done, but gdb would never
approve of the "cp top.c gdbtk-top.c" method.)

Keith

Re: [RFC] Plugins: enhancements

[Tom Tromey]

>>>>> "Keith" == Keith Seitz <keiths@cygnus.com> writes:

Keith> Using the following Makefile.in for rhabout, I can now
Keith> successfully build and install the loadable module "rhabout":

Keith>    include ../Make-rules

This syntax for `include' isn't portable.  Automake has a macro to
check for a few different include styles.  (Note that you can't be
guaranteed that there is any include directive, but such systems
aren't worth worrying about, imnsho.)

Keith> 2) The plugins are currently installed in
Keith> INSTALLDIR/share/insight1.0/plugins.

I agree that this must be changed.  And I think your proposed spot for
it is fine.  The GNU coding standards are pretty clear on these
points.

Suppose I'm writing a third-party plugin.  How will I find this
directory to install my files?  I ask because presumably the version
number is in there anticipating that it will change someday.

One solution would be to have some kind of script that prints out the
relevant information.

Tom

Re: [RFC] Plugins: enhancements

[Keith Seitz]

On 24 Nov 2001, Tom Tromey wrote:

> >>>>> "Keith" == Keith Seitz <keiths@cygnus.com> writes:
>
> Keith> Using the following Makefile.in for rhabout, I can now
> Keith> successfully build and install the loadable module "rhabout":
>
> Keith>    include ../Make-rules
>
> This syntax for `include' isn't portable.  Automake has a macro to
> check for a few different include styles.  (Note that you can't be
> guaranteed that there is any include directive, but such systems
> aren't worth worrying about, imnsho.)

I'd love to use automake, but until I can get a clean split between gdb
and Insight's configury, I don't think this is possible. So for now, I am
stuck with using just Makefile.ins.

> Suppose I'm writing a third-party plugin.  How will I find this
> directory to install my files?  I ask because presumably the version
> number is in there anticipating that it will change someday.

Hmmm. Well, I guess there are some solutions... The third-party plugin
writer includes the copy of Make-rules which will tell it where to put it,
we can, as you say, make some sort of script to tell him where to put it,
or he can put it where ever he wants to, and then just tells Insight where
to find it.

I'm also sitting on patches to add an INSIGHT_PLUGINS environment
variable, which will be a colon-separated list of directories to search
for plugins.

Keith

Re: [RFC] Plugins: enhancements

[Tom Tromey]

>>>>> "Keith" == Keith Seitz <keiths@cygnus.com> writes:

>> This syntax for `include' isn't portable.  Automake has a macro to
>> check for a few different include styles.  (Note that you can't be
>> guaranteed that there is any include directive, but such systems
>> aren't worth worrying about, imnsho.)

Keith> I'd love to use automake, but until I can get a clean split
Keith> between gdb and Insight's configury, I don't think this is
Keith> possible. So for now, I am stuck with using just Makefile.ins.

Yeah.  But you could use the macro from automake to get the correct
`include' syntax.

Another choice would be to use configure's facility to concatenate
multiple files.  That would keep the Makefile.in small but not rely on
make-time includes.

Tom