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

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

[Adam J. Richter]

	linux-2.5.24/drivers/net/hamradio/soundmodem/Makefile contains
the following rule:

$(obj)/sm_tbl_%: $(obj)/gentbl
        $<

	obj was set to "." /usr/src/linux/Rules.make, which was included
earlier in the Makefile.

	The problem is that when make executes this rule it executes
"gentbl" rather than "./gentbl".  This causes the command to fail if
you do not have "." in your path.  Make-3.79.1 is apparently being too
clever in expanding file names.  I think this is a make bug.

	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 $<


Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

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

[Henning Makholm]

Scripsit "Adam J. Richter" <adam@yggdrasil.com>

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

> $(obj)/sm_tbl_%: $(obj)/gentbl
>         $<

> 	obj was set to "." /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

?

I'm not sure this is really a bug either. 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. It is quite reasonable
for $< to unfold to the *canonical* name of the file in question, I
think.

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 $*

-- 
Henning Makholm                                "You are in a little twisting
                                            maze of passages, all different"

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.

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

[Kai Germaschewski]

On Sat, 22 Jun 2002, Riley Williams wrote:

> >> $(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 think I like the latter better as well. Anyway, $(obj) is just "."
currently, so it doesn't have a space in it. For $(src), I'll always use
relative paths, so there won't be any spaces in them either. I think it's
a sensible restriction for separate src/obj trees to disallow spaces in
the obj tree path, I fear it'd cause problems at a huge number of places.
At least it's certainly acceptable to do "no space" first and then see
what needs to be done in order to remove that restriction.

(I also think the two are functionally equivalent even if $(obj) contains 
a space, but I haven't tried at all)

--Kai

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

[Adam J. Richter]

enning Makholm wrote:
>Scripsit "Adam J. Richter" <adam@yggdrasil.com>
>> 	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

	Thanks.  That is a cleaner workaround.



>I'm not sure this is really a bug either. 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. It is quite reasonable
>for $< to unfold to the *canonical* name of the file in question, I
>think.

	That just makes the behavior of make less predictable.
Whatever make does with the file names internally is its own business.
Rewriting the file names passed to commands unnecessarily is
potentially a big problem.  Suppose, for example, that this was a
command that wanted to chop up the directory prefix and that the
bottom level directory was a symbolic link (for example, maybe I have
/usr/netscape/bin as a symlink to /usr/local/bin, but I want the
installation command to record the path name as /usr/netscape/bin).



>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 $*

	Sorry, I do not understand what you mean.  If you want to
explain it to me, you may have to write the rule out.

	Thanks for the better workaround and the advice.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."

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

[Henning Makholm]

Scripsit Riley Williams <rhw@InfraDead.Org>

> >> $(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

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

> 	obj = `pwd`

In which case the command

	PATH=$(obj):$$PATH $<

is likely do fail miserably too.

Also, the dependency list $(obj)/gentbl will be parsed as multiple
files when $(obj) contains spaces. Which is clearly the right
behavior, as it is hard to find a serious project that does not use
Makefile variables to hold the names of multiple dependencies
somewhere.

> ...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.

If one is afraid of that, one can use

	"$(obj)/gentbl"

which will prevent the shell from thinking that the space separates
"words" on the command line. (Whether one can trick make into
interpreting the space as part of the filename in the dependency list
is another matter).

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

> It's a genuine bug that needs fixing.

I still disagree.

> 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.

I don't think that "$<" is documented anywhere to have any exact
relationship to the string of characters used in the depencency
list. The GNU make manual says that $< is "the name of the first
depencency", not "the string used to identify the first dependency in
the rule".

> 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.

Assuming anything for $< (and similar variables) but that they unfold
to SOME name that references the file in question, is open to
misinterpretation and leads to unportable makefiles.

-- 
Henning Makholm                             "... and that Greek, Thucydides"

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

[Henning Makholm]

Scripsit "Adam J. Richter" <adam@yggdrasil.com>

> >I'm not sure this is really a bug either. 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. It is quite reasonable
> >for $< to unfold to the *canonical* name of the file in question, I
> >think.

> 	That just makes the behavior of make less predictable.
> Whatever make does with the file names internally is its own business.
> Rewriting the file names passed to commands unnecessarily is
> potentially a big problem.

It is not rewriting file names. It is just substituting the name of
the dependency for the $< variable, just as documented.

> >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 $*

> 	Sorry, I do not understand what you mean.

It wasn't right anyway. I remembered the semantics of $* when the file
name contains slashes wrong.

-- 
Henning Makholm                      "They are trying to prove a hypothesis,
                             they are down here gathering data every season,
                       they're publishing results in peer-reviewed journals.
                     They're wrong, I think, but they are still scientists."