[FFmpeg-devel] [PATCH] Non-recursive makefiles
Sat Mar 29 01:28:50 CET 2008
Balatoni Denes <dbalatoni at interware.hu> writes:
> 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)
>> > +BREAK=$(SLIBNAME_WITH_MAJOR)
>> > $(SUBDIR)$(SLIBNAME): $(SUBDIR)$(SLIBNAME_WITH_MAJOR)
>> > - cd ./$(SUBDIR) && $(LN_S) $(SLIBNAME_WITH_MAJOR) $(SLIBNAME)
>> > + 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.)
mans at mansr.com
More information about the ffmpeg-devel