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
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 Automake extension
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 will
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 Automake extension
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 this case, an Automake
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
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
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 argument
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
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 being a
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, Dec
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 :(
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?
Yes. In this
* 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 what order
* 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 option.
* 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
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
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
[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 this.
Le 4 déc. 08 à 09:38, Ralf Wildenhues a écrit :
I have a silly question, but... is it really known for a fact that
some
Make out there do not support include if it exists?
This question is not relevant to the problem. Automake requires some
'make'-provided inclusion mechanism to work,
Hi Akim,
* Akim Demaille wrote on Wed, Dec 10, 2008 at 10:21:50AM CET:
Le 4 déc. 08 à 09:38, Ralf Wildenhues a écrit :
I have a silly question, but... is it really known for a fact that
some Make out there do not support include if it exists?
This question is not relevant to the problem.
21 matches
Mail list logo
