> From: Paul Smith <psm...@gnu.org>
> Cc: bug-make@gnu.org
> Date: Sat, 27 Apr 2013 16:58:54 -0400
>
> On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote:
> > That would be nice, indeed.
>
> OK, pushed. You should be able to simply write a new load_objects()
> function and drop it in. Or put it into a w32 file or whatever.
Thanks, I did that.
As result of reading the docs and the code, I have a few comments on
this feature, hopefully it will be useful:
1. Doesn't the FSF frown upon capability to load _any_ dynamic
objects? I think they like the GCC method whereby each extension
is required to define a symbol with a certain name
(plugin_is_GPL_compatible in GCC), which is tested at load time,
before the dynamic object is allowed to be loaded.
2. The fact that the dynamic object's file extension (.so) is exposed
to the Makefile is unfortunate, because it will hurt portability of
Makefiles: the extension on Windows is .dll. Can we omit the
extension and append it internally?
3. I suggest to extend the search for dynamic object to a
Make-specific directory (${prefix}/share/make/), before falling
back to the "system-specific path". Or maybe even not fall back to
any system-specific defaults, because those are generally set for
shared libraries, not for plugins. (You do NOT want to know where
Windows will look for shared libraries.)
4. It would be good to have at least a single simple example of a
dynamic extension, either in the tarball or in the manual. The
only ones I found are in the test suite; did I miss something?
5. Is the following a valid 'load' directive?
load /foo/bar/
If it is valid, what is its semantics? If it is invalid, the code
in load_object should detect it and give a diagnostics; currently
it will happily use this, and will try to call a symbol _gmk_setup.
6. The diagnostics in read.c:
if (! load_file (&ebuf->floc, &name, noerror) && ! noerror)
fatal (&ebuf->floc, _("%s: failed to load"), name);
is IMO misleading: it says "failed to load" also in the case that
the dynamic object was successfully loaded, but the function called
from it returned zero. It would be better to make a more precise
message in that case.
6. API:
. I suggest to request that the buffers for expansions and
evaluation by gmk_expand and gmk_eval be provided by the caller.
It is not safe (and not very convenient) to return buffers
allocated internally by these functions, because the dynamic
object might be compiled/linked with an incompatible
implementation of memory allocation routines.
. The manual says that the setup function should return non-zero on
success, but the code actually requires a non-negative value;
anything else prevents the dynamic object from being recorded in
.LOADED.
HTH
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
