[FFmpeg-devel] [PATCH] Non-recursive makefiles

Måns Rullgård mans
Sat Mar 29 01:28:50 CET 2008

Balatoni Denes <dbalatoni at interware.hu> writes:

> Hi!
> Saturday 29 March 2008 00:32-kor M?ns Rullg?rd ezt ?rta:
>> > diff -Naur ffmpeg/subdir.mak ffmpeg2/subdir.mak
>> > --- ffmpeg/subdir.mak	2008-03-29 00:22:40.000000000 +0100
>> > +++ ffmpeg2/subdir.mak	2008-03-29 00:23:01.000000000 +0100
>> > @@ -19,8 +19,9 @@
>> >
>> >  define RULES
>> >  ifeq ($(BUILD_SHARED),yes)
>> > +	cd ./$(SUBDIR) && $(LN_S) $(BREAK) $(SLIBNAME)
>> Hmm, good question.  How does it fail?  Does it make a difference if
>> you use BREAK:=$(SLIBNAME_WITH_MAJOR) instead (note the colon)?
> It does not make a difference.
> The failure can be seen from this line in the output:
> "cd ./libavutil/ && ln -sf libavcodec.so.51 libavutil.so"
> which is obviously wrong. Okay so at least I have shown that there was some 
> substance to what I was talking about. If you happen to find out what is the 
> reason for the anomaly I would be most interested.

I think I understand what's happening.  It has to do with the order of
evaluation.  When $(eval $(RULES)) is processed, all variable
references within $(RULES) are completely expanded before the result
is evaluated as makefile syntax.  On the first pass over this file,
BREAK is not set, but is assigned the then-current value of
SLIBNAME_WITH_MAJOR in the eval.  This value is substituted into the
rule during the next pass, in which BREAK is assigned the next value
of SLIBNAME_WITH_MAJOR, and so forth, the value of BREAK always one
step behind.  If you move the BREAK assignment outside the definition
of RULES, I reckon it will work as expected.

Moral of the story: do not assign and use the same variable within an
eval directive.  (Unless you really know what you're doing.)

M?ns Rullg?rd
mans at mansr.com

More information about the ffmpeg-devel mailing list