Date: Sun, 19 May 2002 15:21:59 +0200 From: Bernd Walter <ticso@cicely5.cicely.de> To: "J. Mallett" <jmallett@FreeBSD.ORG> Cc: freebsd-current@FreeBSD.ORG Subject: Re: make(1) patch to ReadMakefile() to use realpath(3) Message-ID: <20020519132159.GI44753@cicely5.cicely.de> In-Reply-To: <20020519100420.GA8356@FreeBSD.ORG> References: <20020519100420.GA8356@FreeBSD.ORG>
next in thread | previous in thread | raw e-mail | index | archive | help
Why do people think that a realpath is always available? What is wrong with just extending using pwd? And maybe optionally stripping .. and . elements if wanted. At least pwd doesn't break amd(8) pathnames. It became nearly impossible to use amd(8) today just because of all that realpath introduced breakage. On Sun, May 19, 2002 at 10:04:21AM +0000, J. Mallett wrote: > Often I hear people complain about one lacking in FreeBSD's make(1), if an > error is encountered in a Makefile, we only get the base of its name: what > is passed to ReadMakefile(). This is confusing for people trying to debug > Makefiles, I am told, and really, there's no reason not to always give the > real path to what is passed to ReadMakefile(). > > Therefore, I would like to ask for review of the following patch to main.c > http://people.freebsd.org/~jmallett/make.main.c.realpath.diff > > There is of course the edge case that Dir_FindFile will be used, and it > will somehow give us something that is not a meaningful path. This is > not all that likely, but if it is, I have a patch I use locally which > tells Dir_FindFile to *always* use real paths. This bloats a buildworld > log a tad, oh well, you might find it useful. I'm mostly concerned about > getting the main.c patch reviewed and committed, but here is a patch for > dir.c as well as main.c > http://people.freebsd.org/~jmallett/make.realpath.diff > > One could easily argue though that the dir.c patch will represent an > overhead increase withotu a real gain. > > Because I'm not sure of that, and because what sparked me digging out > these patches from my local make(1) is the FreeBSD user community, I'm > asking for thoughts, opinions, review, and flames from you guys, the > FreeBSD -CURRENT users. If there's anyone who can blow a whole through > this idea, or endorse it enough to make me commit it, it's you guys. > > Here's a small example of what this results in, with "foo/Makefile" being > broken: > > Without these patches: > ref5% make > ===> foo > "Makefile", line 1: Need an operator > make: fatal errors encountered -- cannot continue > *** Error code 1 > > Stop in /d/home/jmallett. > ref5% > > > You can see how one might be confused as to which Makefile that refers. > > With these patches: > ref5% ~/jmake > ===> foo > "/d/home/jmallett/foo/Makefile", line 1: Need an operator > jmake: fatal errors encountered -- cannot continue > *** Error code 1 > > Stop in /d/home/jmallett. > ref5% > > Much clearer. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020519132159.GI44753>