On Tue, 2009-09-08 at 10:12 +0530, Venkata Rajasekharu wrote:
> Hi all,
>
> makefile:
> -
> VAR = 1 $< 1
> all : VAR += 2 $< 2
>
> all: makefile
> echo $(VAR)
> ---
>
> bash-3.00$ make
> 1 1 2 makefile 2
>
> Since VAR is a recursively defined variab
On Tue, Sep 08, 2009 at 10:12:52AM +0530, Venkata Rajasekharu wrote:
> Hi all,
>
> makefile:
> -
>
> VAR = 1 $< 1
> all : VAR += 2 $< 2
>
> all: makefile
> echo $(VAR)
>
> ---
>
> bash-3.00$ make
> 1 1 2 makefile 2
>
> Since VAR is a recursively def
Follow-up Comment #3, bug #27381 (project make):
Thanks for the explanation. I would like to know if the NOSORT is needed to
workaround a bug. Adding $(sort ...) is an acceptable workaround for my
wildcards that needs sorting.
___
Reply
I sent in a bug report the other day and got this as a response.
> From make's NEWS file for the 3.81 release:
>
> * WARNING: Backward-incompatibility!
>
> In order to comply with POSIX, the way in which GNU make processes
> backslash-newline sequences in recipes has changed. If your makef
> All you have to do is use recursive assignment ("=") and NOT simple
assignment (":=").
The attachment did use =, making the coworker's assertion odder. The
lack of need for target-specific variables can be illustrated with a
simple example:
mart...@whitewater:~/playpen/make-splitting$ ca
On Tue, 2009-09-08 at 13:02 -0700, Warren Dodge wrote:
> I tried it on my specific problem and indeed it solved the issue. A
> co-worker was working on another Makefile an having a similar issue. We
> tried the solution above and ran into a number if strange issues.
I haven't looked at this yet bu
On Tue, 2009-09-08 at 13:02 -0700, Warren Dodge wrote:
> I have attached a small tree of files which will show what we are trying
> to do. It has the "runit" script which will process through the
> combinations and save the results in log files.
I have looked at your examples. I'm not sure why th
