Hi :-)
This is a response to a rather old email about loadable modules.
I'm keen to see the patch for the load operator if you have it :-).
On 5 April 2012 15:12, Paul Smith psm...@gnu.org wrote:
Before going too much further note that I've got a semi-implemented
load operator in my source
I have been breaking my head over a simple thing of measuring the progress
of build i.e. I wanted to know how many files are supposed to be built and
how many are already built till now giving an idea of how much more time I
would have to wait.
The only way I could think of this was to have
On Sat, 2012-05-12 at 00:04 +0530, Samkit Jain wrote:
I have been breaking my head over a simple thing of measuring the
progress of build
It's simple to say, but it's not simple to know. The structure of make
and how it performs builds means that it's not possible to know this.
make simply
Knowing make's current idea of where it is would still be nice even if
it keeps changing.
I also would like to hook to the start and end of the execution of
every recipe because there are many uses for this, one of which might
be progress but triggering retries (when unreliable network shares are
On 04/05/2012 11:59 PM, Tim Murphy wrote:
As for other tools like Electric Make, I want to be able to arm-twist
them to support plugins (politely of course, Eric :-) ) without them
being able to say it's impossible or unreliable or that it requires
them to simulate the volatile internals of
Hi,
2012/4/10 Eric Melski s...@melski.net
So there's definitely interest in collaboration on our end; is there any
interest from the gmake devs?
I'm currently working on improving performance of gmake variable expansion
engine. In particular, I have rewritten the way of handling 'call'
Hi :-)
On 6 April 2012 01:16, Paul Smith psm...@gnu.org wrote:
On Thu, 2012-04-05 at 23:59 +0100, Tim Murphy wrote:
I see the value in a plugin system as being that I don't have to
recompile the plugins for every version of make. In a way it's tending
towards why bother if you did have to do
On Fri, Apr 6, 2012 at 2:59 AM, Tim Murphy tnmur...@gmail.com wrote:
I was thinking of marking this feature as experimental in the first
release (in the documentation), just to be more clear on expectations.
Very very much so - there are many platforms to support anyhow and
when someone
Date: Fri, 6 Apr 2012 12:08:33 -0400
From: David Boyce david.s.bo...@gmail.com
Cc: bug-make@gnu.org bug-make@gnu.org
Apropos of this, the Apache Portable Runtime has a nice abstraction
over dlopen and LoadLibrary.
Is it significantly better than what libltdl provides? The advantage
of the
On Fri, Apr 6, 2012 at 12:40 PM, Eli Zaretskii e...@gnu.org wrote:
Date: Fri, 6 Apr 2012 12:08:33 -0400
From: David Boyce david.s.bo...@gmail.com
Cc: bug-make@gnu.org bug-make@gnu.org
Apropos of this, the Apache Portable Runtime has a nice abstraction
over dlopen and LoadLibrary.
Is it
On Fri, 6 Apr 2012, David Boyce wrote:
On Fri, Apr 6, 2012 at 2:59 AM, Tim Murphy tnmur...@gmail.com wrote:
I was thinking of marking this feature as experimental in the first
release (in the documentation), just to be more clear on expectations.
Very very much so - there are many platforms
Date: Fri, 6 Apr 2012 13:30:31 -0400
From: David Boyce david.s.bo...@gmail.com
Cc: tnmur...@gmail.com, bug-make@gnu.org
Sorry, I've never used libltdl. Maybe it would have been better just
to say libraries exist to paper over the differences between various
platforms dynamic linking APIs;
On Fri, 2012-04-06 at 22:35 +0300, Eli Zaretskii wrote:
Date: Fri, 6 Apr 2012 13:30:31 -0400
From: David Boyce david.s.bo...@gmail.com
Cc: tnmur...@gmail.com, bug-make@gnu.org
Sorry, I've never used libltdl. Maybe it would have been better just
to say libraries exist to paper over the
From: Paul Smith psm...@gnu.org
CC: David Boyce david.s.bo...@gmail.com, bug-make@gnu.org
Date: Fri, 6 Apr 2012 16:13:47 -0400
Maybe this is just irrational prejudice but I've never had a good
experience using libtool and I'm SO uninterested in fighting with it in
GNU make.
I will admit
On 6 April 2012 21:55, Eli Zaretskii e...@gnu.org wrote:
From: Paul Smith psm...@gnu.org
CC: David Boyce david.s.bo...@gmail.com, bug-make@gnu.org
Date: Fri, 6 Apr 2012 16:13:47 -0400
Maybe this is just irrational prejudice but I've never had a good
experience using libtool and I'm SO
On Fri, Apr 6, 2012 at 5:36 PM, Tim Murphy tnmur...@gmail.com wrote:
I had a little look at libtdl. To be brutal I thought that using
dlopen/LoadLibrary directly was *much* easier. There isn't really
anything madly complicated about what's being done.
To clarify: when I originally spoke
Hi,
I am between jobs which made me realise that I am absolutely free to
contribute to make for about 10 days :-)
The one thing I have wanted the most and the longest is a way to add
new functions without having to rebuild and look after a custom
version of make. Essentially this should allow
I like this idea quite a bit.
I see this as still work in progress to define what type of functions the
plugins can have.
Maybe they can even create or change make variables.
In the case of variable_buffer_output, I'd suggest that each plugin has an
'initialization function'. This is a
Hi,
On 5 April 2012 20:52, Lawrence Ibarria libar...@nvidia.com wrote:
I like this idea quite a bit.
I see this as still work in progress to define what type of functions the
plugins can have.
Maybe they can even create or change make variables.
At this point, plugins are naughty and are
A few years ago I suggested a plugin architecture much like this (but
I didn't supply a patch - crucial difference), to allow a plugin to
make the up-to-date determination, replacing the hardwired timestamp
system. That could in theory be quite useful as it would allow an MD5
or similar signature
Hi,
On 5 April 2012 23:12, Paul Smith psm...@gnu.org wrote:
Hi Tim;
Before going too much further note that I've got a semi-implemented
load operator in my source already, which fulfills a similar function
except in a less sophisticated way: it just calls a function in the
loaded object
Hi,
On 5 April 2012 23:27, David Boyce david.s.bo...@gmail.com wrote:
A few years ago I suggested a plugin architecture much like this (but
I didn't supply a patch - crucial difference), to allow a plugin to
make the up-to-date determination, replacing the hardwired timestamp
system. That
On Thu, 2012-04-05 at 18:27 -0400, David Boyce wrote:
A few years ago I suggested a plugin architecture much like this (but
I didn't supply a patch - crucial difference), to allow a plugin to
make the up-to-date determination, replacing the hardwired timestamp
system. [...] Any idea how hard
On Thu, 2012-04-05 at 23:59 +0100, Tim Murphy wrote:
I see the value in a plugin system as being that I don't have to
recompile the plugins for every version of make. In a way it's tending
towards why bother if you did have to do that.
Well, this kind of combines with my other issue regarding
24 matches
Mail list logo
