Re: Make loadable extension library

[Tim Murphy]

Many thanks for your response!

On 31 October 2015 at 22:19, Paul Smith <address@hidden> wrote:

> On Thu, 2015-10-29 at 19:02 +0000, Tim Murphy wrote:
> > 1) The return value must be allocated by the function, after which
> > make copies it into a buffer and deallocates it. [...] It seems as if
> > it would be much better to expose GNU make's variable buffer interface
> > and cut out the extra memory allocations
>
> I'm not sure I understand exactly what you have in mind, but you have to
> be careful to avoid the "all the world's a POSIX ELF format" syndrome.
> In some systems shared libraries cannot free memory allocated in other
> dynamic objects.  For example in Windows make shouldn't allocate memory
> and leave a DLL responsible for freeing it (or vice versa).
>
> Given that restriction I'm fine with improving the interface.
>

Hmm, that is a point that I hadn't thought about.

I like the interface for the built-in functions quite a lot. As an
example:
func_strip (char *o, char **argv, const char *funcname UNUSED)

This is then written to by calls like so:

 o = variable_buffer_output (o, word_start, i);

To me this seems almost the ideal interface. The implementation is hidden
but it lets
me cope with output that might be arbitrarily long.

AFAICT this doesn't trip over the restriction any more than the current
interface does.

The only potential improvement would be if I could preallocate some empty
space
at then end a bit like VARIABLE_BUFFER_ZONE but something that one could
specify as a parameter.  This would make it possible to write directly into
the buffer
without any "redundant" use of memcpy.  e.g. instead of snprintf()'ing a
number into
a 10 character buffer and then using variable_buffer_output() to copy that
to the output, I would call

out = variable_buffer_ensurefree(o, 10);
nchars = snprintf(out,10,"%d", number);
o = variable_buffer_advance(out, nchars);

The point being that at  memcpy() is never called by any of these
functions.  This sort of thing might seem a bit trivial but I would imagine
that it has quite an effect on e.g. recursive calls of functions. i.e there
are things which one would like to implement in make with "define" and
"$(call)" but that end up being very slow when you present a long list of
parameters or deep recursion is needed.

Anyhow I can see that to get this to happen, I would have to supply some
sort of patch and that will have to wait a little while. :-)

> 2) There are some functions for seeking tokens in a string that should
> > also be exposed - to help functions process lists.
>
> I agree, although there are too many existing interfaces in make today
> that parse tokens.  I've wanted to try to wrangle them into some
> semblance of order before I try exporting them.
>
> The one I keep wanting is find_next_token (&text, &len).  I don't know the
alternatives yet but I thought I might mention that this one seems to be
used in functions.c quite a lot and it would suit me.

Cheers :-)

Tim