Re: Loadable module support

[Boris Kolpackov]

Hi Paul,

Paul D. Smith <address@hidden> writes:

> Next we need a syntax for loading modules.  I was thinking of something
> like this:
> 
>         load <name> [<pathname>]
> 
> The semantics would be something like this:
> 
>      1. See if the symbol "gmk_<name>_init" (or something?) is defined.
>      2. If not, then loop through the following paths in order:
>         <pathname> (if given), or the expansion of <name> against a list
>         of patterns in a variable such as .LOADPATTERNS, the default
>         value of which would be something like "%.o lib%.so".
>      3. For each one in turn, try loading it with dlopen().  Should we
>         support VPATH search algorithms for these as well?  Do we want
>         to try to suppress normal dlopen() search algorithms
>         (LD_LIBRARY_PATH etc.)?

This sounds overly complex to me. dlopen() (not sure about Windows
LoadLibrary()) doesn't really care about what the name of the module
is. For example, in the GCC plugin architecture you pass a full path
to the name of the module to load. GCC doesn't search LD_LIBRARY_PATH
or append any prefixed (like lib) or suffixes (like .so) to it. Maybe
there is some value in all this (like writing portable modules) though
I am not sure how useful this will be since building a shared object/DLL
is already not portable. Can you maybe give a motivating example for
these features?


> Do we need to introduce "-load" vs. "load", like we have "-include" vs.
> "include", so that we can ignore errors if a module cannot be loaded?

Yes, I think so. Some modules can provide some optional optimizations
(like functions that do things faster), for example.


> I was wondering if we should allow a syntax like:
> 
>         load <name> [<pathname> [<arguments>]]
> 
> and then pass the string containing <arguments> to the "gmk_<name>_init"
> function... maybe this would allow the makefile to customize the
> behavior somehow.  I don't know if this is just adding valueless
> complexity.

I think this can be useful. GCC allows one to pass command line options
to the plugin.


> My intention is to not make any extra effort (beyond defining an
> interface for registering new functions) to provide any defined internal
> interfaces for these modules.  If they want to take advantage of some
> other functions in make code they can but there is no guarantee that
> they will exist, unchanged, in the next release of GNU make.

Yes, I think this is a good approach. However, to allow the plugin
to do more we will need to install the make headers. I would suggest
the /usr/include/make/ directory for that (I would also use the 'make'
prefix instead of 'gmk' in function names; or 'gmake' if 'make' feels
too generic).

Also, it would be good to define a make variable which contains the
path to the directory containing the headers, e.g., .MAKE_HEADERS.
So that we can add the necessary -I option when building the module.

Otherwise looks great.

Boris

-- 
Boris Kolpackov, Code Synthesis      http://codesynthesis.com/~boris/blog
Compiler-based ORM system for C++    http://codesynthesis.com/products/odb