>
> >
[snip]
>
> Also thinking this a little further: especially when I'm working at
> home
> on some free software, I have sometimes only half an hour or something
> like that to spend on developing; I *don't* want to spend this time
> maintaining the build mechanism!! Really: I don't want to do
>
> On Wed, 10 Dec 2008, NightStrike wrote:
> >
> > Ok, so again, I should be allowed to accept that *potential* risk as
> > being far less than the current situation of *actual* risk which is
> > causing problems. If I knew anything about Perl, I'd just do it
> > myself, but alas, the automake s
Bob Friesenhahn wrote:
On Wed, 10 Dec 2008, NightStrike wrote:
Ok, so again, I should be allowed to accept that *potential* risk as
being far less than the current situation of *actual* risk which is
causing problems. If I knew anything about Perl, I'd just do it
myself, but alas, the automake
* NightStrike wrote on Wed, Dec 10, 2008 at 04:46:28PM CET:
> Shouldn't the onus be on me, as the project maintainer, to accept that
> risk and craft the wildcards properly? I for one would wager heavily
> that the probability of that being a problem is FAR less than the
> current problems of main
* NightStrike wrote on Wed, Dec 10, 2008 at 04:25:58PM CET:
>
> If automake has the ability to flatten the += syntax so that
> non-portable make advances can be used, why can't the same logic apply
> to wildcard usage? The biggest argument against it that I've heard is
> that it is a GNU-only opt
* Jan Engelhardt wrote on Wed, Dec 10, 2008 at 04:32:24PM CET:
> On Wednesday 2008-12-10 16:04, Bob Friesenhahn wrote:
> >>> i.e., automake will flatten the += and 'make' won't ever see it.
> >
> > I didn't really trust += in my own Automake makefiles since it was not
> > really
> > clear to me in
Hi Bob,
* Bob Friesenhahn wrote on Wed, Dec 10, 2008 at 04:04:23PM CET:
> On Wed, 10 Dec 2008, Tom Browder wrote:
>>> * Tom Browder wrote on Wed, Dec 10, 2008 at 01:38:53AM CET:
Is it "legal" to use the "+=" operator in lieu of "\" when listing
members of a variable in Makefile.am's?
>>>
On Wed, 10 Dec 2008, NightStrike wrote:
Ok, so again, I should be allowed to accept that *potential* risk as
being far less than the current situation of *actual* risk which is
causing problems. If I knew anything about Perl, I'd just do it
myself, but alas, the automake source confounds me :(
Message: 4
Date: Wed, 10 Dec 2008 07:39:04 +0100
From: Ralf Wildenhues <[EMAIL PROTECTED]>
Subject: Re: GNU Make Extensions
To: Tom Browder <[EMAIL PROTECTED]>
Cc: automake@gnu.org
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
Hello Tom,
* Tom Browder wrote on Wed, D
On Wed, Dec 10, 2008 at 10:57 AM, Bob Friesenhahn
<[EMAIL PROTECTED]> wrote:
> On Wed, 10 Dec 2008, NightStrike wrote:
>
>> Shouldn't the onus be on me, as the project maintainer, to accept that
>> risk and craft the wildcards properly? I for one would wager heavily
>> that the probability of that
On Wed, 10 Dec 2008, NightStrike wrote:
Shouldn't the onus be on me, as the project maintainer, to accept that
risk and craft the wildcards properly? I for one would wager heavily
that the probability of that being a problem is FAR less than the
current problems of maintaining the source file l
On Wed, Dec 10, 2008 at 10:35 AM, Bob Friesenhahn
<[EMAIL PROTECTED]> wrote:
> On Wed, 10 Dec 2008, NightStrike wrote:
>
>> If automake has the ability to flatten the += syntax so that
>> non-portable make advances can be used, why can't the same logic apply
>> to wildcard usage? The biggest argum
On Wed, 10 Dec 2008, Jan Engelhardt wrote:
I didn't really trust += in my own Automake makefiles since it was not really
clear to me in what order the appending would occur
Would it matter? Except for use of := (which I think is non-portable
too), expansion of ${variables} will happen at the l
On Wed, 10 Dec 2008, NightStrike wrote:
If automake has the ability to flatten the += syntax so that
non-portable make advances can be used, why can't the same logic apply
to wildcard usage? The biggest argument against it that I've heard is
that it is a GNU-only option. However, I've suggeste
On Wednesday 2008-12-10 16:04, Bob Friesenhahn wrote:
> On Wed, 10 Dec 2008, Tom Browder wrote:
>>> * Tom Browder wrote on Wed, Dec 10, 2008 at 01:38:53AM CET:
>>> > Is it "legal" to use the "+=" operator in lieu of "\" when listing
>>> > members of a variable in Makefile.am's?
>>>
>>> Yes. In t
On Wed, Dec 10, 2008 at 1:39 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>
> Hello Tom,
>
> * Tom Browder wrote on Wed, Dec 10, 2008 at 01:38:53AM CET:
> > Is it "legal" to use the "+=" operator in lieu of "\" when listing
> > members of a variable in Makefile.am's?
>
> Yes. In this case, an Au
On Wed, 10 Dec 2008, Tom Browder wrote:
* Tom Browder wrote on Wed, Dec 10, 2008 at 01:38:53AM CET:
Is it "legal" to use the "+=" operator in lieu of "\" when listing
members of a variable in Makefile.am's?
Yes. In this case, an Automake extension over portable make syntax,
i.e., automake wil
On Wed, Dec 10, 2008 at 12:39 AM, Ralf Wildenhues
<[EMAIL PROTECTED]> wrote:
> Hello Tom,
>
> * Tom Browder wrote on Wed, Dec 10, 2008 at 01:38:53AM CET:
>> Is it "legal" to use the "+=" operator in lieu of "\" when listing
>> members of a variable in Makefile.am's?
>
> Yes. In this case, an Autom
Le 9 déc. 08 à 23:57, Clint Adams a écrit :
[For the automake guys, the question is whether it's possible to have
a computed name for a (libtool) library.]
On Tue, Dec 09, 2008 at 10:44:44PM +0100, Akim Demaille wrote:
I have written this because that's how it appears in the script
itself
19 matches
Mail list logo
