Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id <S312681AbSFXMAM>; Mon, 24 Jun 2002 08:00:12 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org
	id <S312938AbSFXMAL>; Mon, 24 Jun 2002 08:00:11 -0400
Received: from hugin.diku.dk ([130.225.96.144]:64273 "HELO hugin.diku.dk")
	by vger.kernel.org with SMTP id <S312681AbSFXMAI>;
	Mon, 24 Jun 2002 08:00:08 -0400
To: Riley Williams <rhw@InfraDead.Org>
Cc: "Adam J. Richter" <adam@yggdrasil.com>, bug-make@gnu.org,
       Linux Ham Radio <linux-hams@vger.kernel.org>,
       Linux Kernel <linux-kernel@vger.kernel.org>, sailer@ife.ee.ethz.ch
Subject: Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem
References: <Pine.LNX.4.21.0206222052540.15173-100000@Consulate.UFP.CX>
X-My-Web-page: http://www.diku.dk/~makholm/
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
From: Henning Makholm <henning@makholm.net>
Date: 24 Jun 2002 14:00:09 +0200
In-Reply-To: Riley Williams's message of "Sat, 22 Jun 2002 21:23:27 +0100 (BST)"
Message-ID: <yahsn3clwdy.fsf@pc-043.diku.dk>
X-Mailer: Gnus v5.7/Emacs 20.7
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2801
Lines: 70

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"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/