> > > > > 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 majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
