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
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 e...@gnu.org wrote:
2. The fact that the dynamic object's file extension (.so) is exposed
to the Makefile is unfortunate, because it will hurt
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
Date: Mon, 29 Apr 2013 18:19:09 +0100
From: Tim Murphy tnmur...@gmail.com
Cc: Paul D. Smith psm...@gnu.org, 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, because it will hurt portability of
From: Paul Smith psm...@gnu.org
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
On 29 April 2013 20:12, Eli Zaretskii e...@gnu.org wrote:
Date: Mon, 29 Apr 2013 18:19:09 +0100
From: Tim Murphy tnmur...@gmail.com
Cc: Paul D. Smith psm...@gnu.org, bug-make@gnu.org
bug-make@gnu.org
2. The fact that the dynamic object's file extension (.so) is exposed
to the
Date: Mon, 29 Apr 2013 20:40:46 +0100
From: Tim Murphy tnmur...@gmail.com
Cc: Paul D. Smith psm...@gnu.org, bug-make@gnu.org 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
Date: Mon, 29 Apr 2013 22:34:51 +0300
From: Eli Zaretskii e...@gnu.org
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.
