> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
>> if FOO
>> var = a b
>> endif
>> derived = $(var:%=%.c)
>> if BAR
>> var = c d
>> endif
Derek> Isn't the order irrelevant here since derived won't be
Derek> evaluated until it's used?
No, because we're talking about having automake it
Tom Tromey wrote:
> if FOO
> var = a b
> endif
> derived = $(var:%=%.c)
> if BAR
> var = c d
> endif
Isn't the order irrelevant here since derived won't be evaluated until
it's used?
Um, the gmake manual calls this "expanded when read, except for the shell
commands i
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Following up my own post...
Tom> if FOO
Tom> var = a b c
Tom> else
Tom> var = d e f
Tom> endif
Tom> derived = $(var:%=%.c)
Tom> Will this work correctly? In this situation we have to give
Tom> `derived' the same cond
> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
Alex> + (read_main_am_file): call expand_contents to output
Alex> + variables.
I'm concerned about this (referenced) part of the patch.
Suppose we have a Makefile.am like this:
if FOO
var = a b c
else
var = d e f
endif
> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
Alex> Here is a new version of the patsubst patch against cvs HEAD.
Sorry I haven't been following this thread until now. Only in the
last few weeks have I really started reading automake email again. If
your message is buried too deep i
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
>> -($from = $2) =~ s/(\W)/\\$1/g;
>> +($from = $2) =~ s/(\W)/$1/g;
Pavel> I don't understrand this. This change will affect the
Pavel> traditional rules as well. It should probably be a separate
Pavel> patch if it
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Yep, by default Automake must not let the users do nonportable
Akim> things. I'm sorry about that, but I believe it's a strong
Akim> requirement.
I'm finally following up to this -- it was buried in my overly large
automake mailbox
> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes:
Kevin> It'd be nice to be able to embed little fragments of perl to do
Kevin> things like that, for the "static" case that is. But perhaps
Kevin> that idea has come up before.
I've long resisted letting the user extend Makefile.am with Per
Pavel Roskin writes:
>
> > - ($from = $2) =~ s/(\W)/\\$1/g;
> > + ($from = $2) =~ s/(\W)/$1/g;
>
> I don't understrand this. This change will affect the traditional rules as
> well. It should probably be a separate patch if it fixes a separate issue.
> You may even need
Hello, Alex!
> Here is a new version of the patsubst patch against cvs HEAD.
Thanks! Were are getting closer.
> + * automake.in (expand_contents): add new function to perform
> + the patsubst expansion
> + (value_to_list): add support for patsubst style variable
> + substitution
Here is a new version of the patsubst patch against cvs HEAD.
It is now smaller due to the removal of a superflous option, and has
my instead of local etc. Also the conditional test is improved.
After applying the patch remember to make the .test files
executable. That has caught me out on mor
Hi Pavel,
Thanks for your comments, I'll put together a new patch taking them
into account.
Removing the new command line option will simplify things and get rid
of the need for the second call to handle_options.
Regards,
Alex.
Hello, Alex!
Sorry for another delay. Your patch is very important, but unfortunately
I'm have been very busy recently.
> Here is an updated patsubst patch against CVS automake. Any patsubst
> style variables are now staticly expanded by automake, thus avoiding
> make portability problems.
We n
Hello,
Here is an updated patsubst patch against CVS automake. Any patsubst
style variables are now staticly expanded by automake, thus avoiding
make portability problems.
I have included tests for both the normal and conditional cases of
variable expansion.
Please consider this for checkin.
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Hello! Trying to catch up with the mailing lists :-)
Pavel> I'm surprised that this patch has not been applied since
Pavel> October. I believe it's very valuable. I even considered doing
Pavel> it myself.
We ended stuck with a po
Hello!
Trying to catch up with the mailing lists :-)
I'm surprised that this patch has not been applied since October. I
believe it's very valuable. I even considered doing it myself.
> b) default static expansion to off, avoids surprising anyone depending
>on dynamic expansion by make, ret
Alex Hornby <[EMAIL PROTECTED]> writes:
>
> # Makefile.am fragment
> FOO = foo bar
> BAR = ${FOO:%=%.c}
> ...
>
> What do people think?
It'd be nice to be able to embed little fragments of perl to do things
like that, for the "static" case that is. But perhaps that idea has
come up before. Or
On Oct 28, 2000, Alex Hornby <[EMAIL PROTECTED]> wrote:
> What is the policy regarding changes to non-portable behavour?
automake is supposed to generate portable Makefiles, so I think the
default should be static expansion.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~ol
Alexandre Oliva writes:
> On Oct 27, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
>
> > Yep, by default Automake must not let the users do nonportable
> > things.
>
> I tend to agree. But I wouldn't say `must not', I'd say `should not'.
What is the policy regarding changes to non-porta
On Oct 27, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote:
> Yep, by default Automake must not let the users do nonportable
> things.
I tend to agree. But I wouldn't say `must not', I'd say `should not'.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Deve
| Akim Demaille writes:
| >
| > Sorry, I'm confused, and the documentation snippet didn't really
| > enlighten me :(
| >
|
| Hi Akim,
|
| The reasoning was fairly tortured :)
|
| To document the patsubst internal change I had to invent a contrived
| example so that the user could see the
Akim Demaille writes:
>
> Sorry, I'm confused, and the documentation snippet didn't really
> enlighten me :(
>
Hi Akim,
The reasoning was fairly tortured :)
To document the patsubst internal change I had to invent a contrived
example so that the user could see the expansion. That example
> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
Alex> Akim,
Alex> Okay, here is patsubst patch v2.
Thanks!
Alex> The _PROGRAMS based example in the documentation needs a
Alex> patsubst supporting make (e.g. GNU and Solaris work). This is
Alex> because the program target writes prog_SOU
Akim,
Okay, here is patsubst patch v2. New since last time:
* ChangeLog entry formatting
* NEWS entry
* Documentation (first texinfo usage, please beware!)
The _PROGRAMS based example in the documentation needs a patsubst
supporting make (e.g. GNU and Solaris work). This is because the
program
| Akim,
Hi Alex,
Glad to see your progresses!
| Here is a patch to add patsubst support to value_to_list. I've
| included a new test case "patsubst.test" as well.
That's great news! Thanks a lot!
But I'm going to be a pain, especially because I'm not the official
maintainer of Automake, an
Akim,
Here is a patch to add patsubst support to value_to_list. I've
included a new test case "patsubst.test" as well.
After applying the patch you will need to make patsubst.test
executable, as I haven't yet found a way to make diffs include
permissions :)
Cheers,
Alex.
diff -r -P -u automa
26 matches
Mail list logo
