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 wrote:
> Before going too much further note that I've got a semi-implemented
> "load" operator in my source already, whi
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
Yeah, I guess what I was thinking simple is more complex to code.
But considering this kind of request is coming to GNU make since a couple
years now(the first I saw was in 2007), there should be a way to handle it
in generic manner.
But obviously saying is easier than doing, so I will also start r
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 s
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 hook/ca
Hi,
2012/4/10 Eric Melski
> 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'
arguments and itera
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 ma
On Fri, Apr 6, 2012 at 5:36 PM, Tim Murphy 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 about APR, I was not
On 6 April 2012 21:55, Eli Zaretskii wrote:
>> From: Paul Smith
>> CC: David Boyce , 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 m
> From: Paul Smith
> CC: David Boyce , 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 that my distaste is so extre
On Fri, 2012-04-06 at 22:35 +0300, Eli Zaretskii wrote:
> > Date: Fri, 6 Apr 2012 13:30:31 -0400
> > From: David Boyce
> > 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 difference
> Date: Fri, 6 Apr 2012 13:30:31 -0400
> From: David Boyce
> 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; consider not rei
On Fri, 6 Apr 2012, David Boyce wrote:
On Fri, Apr 6, 2012 at 2:59 AM, Tim Murphy 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
On Fri, Apr 6, 2012 at 12:40 PM, Eli Zaretskii wrote:
>> Date: Fri, 6 Apr 2012 12:08:33 -0400
>> From: David Boyce
>> Cc: "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
> Date: Fri, 6 Apr 2012 12:08:33 -0400
> From: David Boyce
> Cc: "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 latter is that it's readily ava
On Fri, Apr 6, 2012 at 2:59 AM, Tim Murphy 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 eventually trie
Hi :-)
On 6 April 2012 01:16, Paul Smith 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 that.
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 regard
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 h
ng up variable values at the least is also probably
>> important. Another thing I've wanted for ages is to be able to know
>> if some target was declared already - I want plugins to have the
>> ability to look at make's target database if possible although not
>> n
Hi,
On 5 April 2012 23:12, Paul Smith 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 after load
om: bug-make-bounces+libarria=nvidia@gnu.org
>> [mailto:bug-make-bounces+libarria=nvidia@gnu.org] On Behalf Of Tim Murphy
>> Sent: Thursday, April 05, 2012 2:51 AM
>> To: bug-make@gnu.org
>> Subject: Patch to allow make to load plugins that add new functions.
>&g
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 after loading and that function can do whatever it wants.
I can sen
rds,
Tim
> -Original Message-
> From: bug-make-bounces+libarria=nvidia@gnu.org
> [mailto:bug-make-bounces+libarria=nvidia@gnu.org] On Behalf Of Tim Murphy
> Sent: Thursday, April 05, 2012 2:51 AM
> To: bug-make@gnu.org
> Subject: Patch to allow make to load plugins that
riginal Message-
From: bug-make-bounces+libarria=nvidia@gnu.org
[mailto:bug-make-bounces+libarria=nvidia@gnu.org] On Behalf Of Tim Murphy
Sent: Thursday, April 05, 2012 2:51 AM
To: bug-make@gnu.org
Subject: Patch to allow make to load plugins that add new functions.
Hi,
I am between job
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 pe
26 matches
Mail list logo
