[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

From: Eli Zaretskii
Subject: Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)
Date: Mon, 29 Apr 2013 19:33:49 +0300

> From: Paul Smith <address@hidden>
> Cc: address@hidden
> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]