Date: Mon, 7 Jun 1999 13:21:36 -0600 From: Nate Williams <nate@mt.sri.com> To: Chuck Robey <chuckr@picnic.mat.net> Cc: Nate Williams <nate@mt.sri.com>, David Scheidt <dscheidt@enteract.com>, freebsd-current@FreeBSD.ORG Subject: Re: bsd.lib.mk "@"'s Message-ID: <199906071921.NAA08649@mt.sri.com> In-Reply-To: <Pine.BSF.4.10.9906071515250.679-100000@picnic.mat.net> References: <199906071914.NAA08597@mt.sri.com> <Pine.BSF.4.10.9906071515250.679-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > Why are many of the build lines in bsd.lib.mk hidden with leading @'s, > > > > > so that they don't display in the build? This is useless, it hides > > > > > things that go wrong, and hardly belongs here, it seems to me. > > > > > > > > > > > > > How often do your calls to ld, mv and rm fail? > > > > > > That's not the point, the point is that current is a bleeding edge > > > thing, not production, and the details should not be hidden, there's no > > > possible justification for that. > > > > Sure there is, in the same manner that we don't use 'cc -v' as the > > command line parameters to see *all* the excruciating details of how a > > program is compiled. > > > > The '@' calls are not considered important details, and as such are > > hidden. If we include *EVERYTHING* then finding the actual problem is > > often much harder due to trying to wade through the noise. > > > > The '@' commands help to reduce the noise, giving us a better > > signal/noise ratio. > > On a buildworld, Nate? bsd.lib.mk is used in all 'builds', not just buildworld. When I do the following sets of commands: # cd /usr/src/lib/libc # make I also use bsd.lib.mk. I don't *care* about the '@' commands. > Who's worried about signal to noise there? I am, if I'm the developer trying to debug a user's problem. Wading through 1-2M of logfiles to find a problem is much less likely than me wading through 100-200K of logfiles. > Being clean comes into play when you're seeing the same damn thing, day > in and day out. When it comes to troubleshooting, and that's the only > reason to look at that listing, I want as much detail as I can get. It's only useful information if it can *HELP* you debug the problem, and I'll argue that 99/100 times, that information is rarely helpful. Engineering practice suggests optimizing your solution for the 'normal' case, not the boundary case. Nate 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?199906071921.NAA08649>