Date: Sun, 12 Jul 1998 20:47:40 -0400 (EDT) From: Thomas David Rivers <rivers@dignus.com> To: freebsd-hackers@freefall.cdrom.com, joelh@gnu.org Subject: Re: Improvemnet of ln(1). Message-ID: <199807130047.UAA15906@lakes.dignus.com> In-Reply-To: <199807122259.RAA02889@detlev.UUCP>
next in thread | previous in thread | raw e-mail | index | archive | help
> > >> I will personally buy a beer (so long as it's not an American beer) > >> for the first five people who can show me current existance of such a > >> script. (In other words, a script written during or after this > >> discussion doesn't count.) That said, I sincerely doubt I'll have to > >> buy a single beer. > > I don't know if this counts - > > If it's existing code that runs on BSD, whether public or private, it > counts. I don't want to break anything. > > Let me make sure I've got all the details. > > > but the source/build management system at SAS would > > break... technically, it's a program that scans the output. The > > code doesn't employ reasonable return-codes for some ungodly > > reasons, and thus, there are 'scraping scripts' that read through > > several gigs worth out shell/compiler/utility output and "decide" if > > the build was successful. > > Ugh. Believe me - that's being polite! The entire setup suffers from what I call the "bailing" problem. That is, "we're too busy bailing water to steer the ship off of the reef into a dock for repairs." > > > Changing the behaviour of ln, as you suggest, would likely break all > > of that 'log scraping' code. [Who knows how many questionable 'ln' > > commands are embedded within this spaghetti.] > > By questionable ln commands, you mean ln -s's that link to files that > don't exist at the time of the command is issued? Most assuredly... the intent is for the files to (hopefully) exist at a future time... Part of it is builds; part of it build-area management, etc... > > > Believe me; as I'm the manager of the compiler group; and I am > > expressly prohibited from changing even the smallest typo in a > > compiler message; much less adding a new one - for fear of such a > > calamity. The argument is that a broken 'script scraper' costs > > several thousands of developers a couple of days while it's > > repaired... we're talking man-years here of wasted time... I don't > > buy it myself - but that's the rule I live under. > > Okay. If it is your own belief that adding a new message would break > things, then I'll accept that. (I just want it to be your own belief, > not something handed down on high that you believe is a product of > FUD.) Actually, it's a combination of both. My own experience has caused "thundering hurds" of people to call me up; whereby we beat a hasty retreat to a previous revision of a compiler. [The appellation there was someone elses, not my own :-) ] However, I'm convinced a good percentage of the concern was simply FUD. As far as "break" something - it would inconvenience a large group of developers (which costs money.) > > If this code does these things, that is: (1) Creates a symbolic link > to a file that doesn't exist at the time, and (2) analyzes the output > of ln's stderr, and (3) would likely break on the addition of a new > line in the input of [2], then please email me with the name of your > favorite beer, and the address of the liquor store where you want to > pick it up. (Alternatively, if you live in Texas, I may be in your > area soon, and would be happy to buy you the beer in person.) However; you bring up another point. The code I'm thinking of doesn't actually run on FreeBSD, it's on HP/UX at the moment. Only a portion of the builds currently run on FreeBSD.... so, the entire discussion is moot :-) [sorry to drag it out... I didn't realize that at the start.] And, unfortunately; I'm in Raleigh NC... and can no longer drink beer... But; if you're ever in the area - look me up! - Dave Rivers - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807130047.UAA15906>