Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

[Riley Williams]

Hi Henning.

> [Warning: I am not the make maintainer; I just lurk on bug-make]

Fair warning...

>> $(obj)/sm_tbl_%: $(obj)/gentbl
>>         $<
>>
>> obj was set to "." in /usr/src/linux/Rules.make, which was included
>> earlier in the Makefile.
>>
>> Until the make bug is fixed, I have worked around the problem
>> by replacing the rule with:
>>
>> $(obj)/sm_tbl_%: $(obj)/gentbl
>>         PATH=$(obj):$$PATH $<

> That looks like an excessively complicated workaround. Why not just
>
> $(obj)/sm_tbl_%: $(obj)/gentbl
>       $(obj)/gentbl
>
> instead ?

I'm no expert on Makefile syntax, but I am aware of one possible
difference between those two versions with SOME versions of Make and
I believe this Makefile has been carefully crafted to work with all
versions thereof.

The difference will only show up if $(obj) expands to a string with
spaces in it, generated by a definition such as...

        obj = `pwd`

...due to a difference in how SOME versions of Make handle that. My
experience has been that all versions of Make expand "dependency" tokens
as a single token, and copy them down as a single token when $< or the
like are used, but expand the $(obj) in the command line as multiple
tokens in that case. As an example, say that your version of that
definition had been used with the obj=`pwd` definition when the current
directory was "/home/michael/source files/ax25" and we see that the
dependency is correctly interpreted as...

        "/home/michael/source files/ax25/gentbl"

...but the command that follows is taken as being...

        /home/michael/source

...with a parameter of...

        files/ax25/gentbl

...which is clearly not what was intended.

> I'm not sure this is really a bug either.

It's a genuine bug that needs fixing.

> It is a Good Thing that make tries to normalize the names of targets
> and dependencies internally, lest the build may be incomplete or
> redundant if make does not realize that foo.bar and ./foo.bar is the
> same file.

Providing "internally" relates only to internal transliterations done on
the files listed on the dependency line for the purpose of determining
whether a particular file is up to date, and does not also relate to the
use of those files in the rules that follow, there's no problem there.

However, using ANY sort of transliteration with commands listed below
those lines is completely counter-intuitive, and 

> It is quite reasonable for $< to unfold to the *canonical* name of
> the file in question, I think.

The ONLY reasonable canonical name for ANY file is that which includes
the full path to that file starting from the root directory and working
down through real directories without encountering any symbolic links.
Absolutely anything else is open to misinterpretation.

> If one absolutely wants the command to use the exact form of the
> dependency that's used in the dependency list, it's easy to simply
> reproduce that form, replacing the % by $*

By doing so, one introduces unacceptable bugs in many cases, simply due
to differing treatment of the two cases by different versions of make.

Best wishes from Riley.