> Date: Mon, 29 Apr 2013 22:34:51 +0300
> From: Eli Zaretskii
> Cc: bug-make@gnu.org
>
> > Also we don't really have a precedent of a "make-specific" directory
> > like that.
>
> Gawk puts them into ${prefix}/lib/gawk.
Correction: ${prefix}/lib/gawk-extensions.
> Date: Mon, 29 Apr 2013 20:40:46 +0100
> From: Tim Murphy
> Cc: "Paul D. Smith" , "bug-make@gnu.org"
>
> > How can one deal with them? The underlying OS is not easily
> > detectable by Make.
> >
>
> the same way one creates 1 makefile that can build the same code for 2
> operating systems - s
On 29 April 2013 20:12, Eli Zaretskii wrote:
> > Date: Mon, 29 Apr 2013 18:19:09 +0100
> > From: Tim Murphy
> > Cc: "Paul D. Smith" , "bug-make@gnu.org" <
> bug-make@gnu.org>
> >
> > > 2. The fact that the dynamic object's file extension (.so) is exposed
> > >to the Makefile is unfortunate,
> From: Paul Smith
> Cc: bug-make@gnu.org
> Date: Mon, 29 Apr 2013 13:59:16 -0400
>
> > 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_
> Date: Mon, 29 Apr 2013 18:19:09 +0100
> From: Tim Murphy
> Cc: "Paul D. Smith" , "bug-make@gnu.org"
>
> > 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
I must clarify - I think that make should provide plugins with an
allocation mechanism. Not the other way around.
the snprintf model for dealing with expansion is not so bad - I mean the
problem is that nobody knows how big an expansion is going to be in the
end, right? So how does make deal wit
On Mon, 2013-04-29 at 19:33 +0300, Eli Zaretskii wrote:
> > From: Paul Smith
> > 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 writ
Sorry to keep adding in my 2c but I have also submitted a plugin
implementation so I have a couple of ideas
On 29 April 2013 17:33, Eli Zaretskii wrote:
>
> 2. The fact that the dynamic object's file extension (.so) is exposed
>to the Makefile is unfortunate, because it will hurt portabilit
> From: Paul Smith
> 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
