On Mon, 2007-12-10 at 21:51 +, Olly Betts wrote:
>
> I can't think of a way to easily dig out statistically useful data
> from a VCS or Google code search on how often it happens either to me
> or
> generally. But I mainly offered it as a more concrete example of the
> sort of issues I had i
On Wed, Nov 28, 2007 at 07:15:10PM +0100, Ralf Wildenhues wrote:
> elc-stamp: $(elc_stamp_SOURCES)
> @rm -f [EMAIL PROTECTED]
> @touch [EMAIL PROTECTED]
> $(elc_stamp_COMMAND)
> @mv -f [EMAIL PROTECTED] $@
Hmm, what's the reason for "rm -f" before "touch" here?
Cheers,
On Mon, Dec 10, 2007 at 09:15:26AM +0100, Ralf Wildenhues wrote:
> * Olly Betts wrote on Sun, Dec 09, 2007 at 03:53:11AM CET:
> > On Wed, Nov 28, 2007 at 07:15:10PM +0100, Ralf Wildenhues wrote:
> > > That would drive us
> > > further away from being able to copy the contents of Makefile.am into
>
Hello Olly,
* Olly Betts wrote on Sun, Dec 09, 2007 at 03:53:11AM CET:
> On Wed, Nov 28, 2007 at 07:15:10PM +0100, Ralf Wildenhues wrote:
> > * Olly Betts wrote on Tue, Nov 27, 2007 at 01:30:31AM CET:
>
> > > data.c data.h::: data.foo
> > > foo data.foo
> >
> > Yuck. Let's bette
On Wed, Nov 28, 2007 at 07:15:10PM +0100, Ralf Wildenhues wrote:
> * Olly Betts wrote on Tue, Nov 27, 2007 at 01:30:31AM CET:
> > I don't have a concrete proposal, but it seems that this would need
> > to be controllable rather than automatically adjusting any rule with
> > multiple targets, if onl
Hello Olly,
Thanks for bringing this up.
* Olly Betts wrote on Tue, Nov 27, 2007 at 01:30:31AM CET:
> I've read (and use the recipes from) the automake manual section
> "Handling Tools that Produce Many Outputs". However, these recipes
> require a lot of boilerplate code which annoyingly obscure
On 2007-11-27, Bob Friesenhahn <[EMAIL PROTECTED]> wrote:
> On Tue, 27 Nov 2007, Olly Betts wrote:
>> My experience is that multi-output rules often aren't protected at all,
>> and parallel make is unreliable on such projects. This is becoming much
>> more of an issue, as multicore boxes are now m
On Tue, 27 Nov 2007, Olly Betts wrote:
My experience is that multi-output rules often aren't protected at all,
and parallel make is unreliable on such projects. This is becoming much
more of an issue, as multicore boxes are now mainstream.
What relationship is there between parallel make and m
On Nov 27, 2007 9:54 AM, Olly Betts <[EMAIL PROTECTED]> wrote:
>
> In fact, none of the real examples I have to hand fit into the mould of
> a collection of implicit rules with a common basename.
>
> Cheers,
> Olly
Just to toss a couple more pennies into the pot, I am currently working
on a po
On 2007-11-27, Stepan Kasal <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 27, 2007 at 12:30:31AM +, Olly Betts wrote:
>> data.c data.h::: data.foo
>> foo data.foo
>
> But this looks like too much magic for a feature which is not used
> that much.
My experience is that multi-output r
Hello,
On Tue, Nov 27, 2007 at 12:30:31AM +, Olly Betts wrote:
> "Handling Tools that Produce Many Outputs". However, these recipes
> require a lot of boilerplate code which annoyingly obscures [...]
>
> It's just struck me that automake is good at inserting lots of
> boilerplate code into m
I've read (and use the recipes from) the automake manual section
"Handling Tools that Produce Many Outputs". However, these recipes
require a lot of boilerplate code which annoyingly obscures the actual
rule they are protecting - a two line rule is swamped by a dozen lines of
boilerplate.
It's ju
12 matches
Mail list logo
