Date: Fri, 09 Feb 1996 02:11:26 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: asami@cs.berkeley.edu (Satoshi Asami) Cc: ports@freebsd.org Subject: Re: cvs commit: ports/lang/expect/scripts configure Message-ID: <19141.823860686@time.cdrom.com> In-Reply-To: Your message of "Fri, 09 Feb 1996 01:36:19 PST." <199602090936.BAA00793@silvia.HIP.Berkeley.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
> Considering the ugliness of the hack that is required to make these > "evil" ports happy (did you see what I had to do to expect?), adding a > private header or two (which are part of freely available sources > anyway) to our /usr/local (we can even make a separate directory with > a red flashing warning) is really not that bad. Sorry, I really just can't agree. I don't even feel that it's an apples and apples comparison in the case of these two hacks; one is a build hack which takes some extra CPU time and wastes disk space but ultimately leaves /usr/local in the correct shape (e.g. it acheives exactly the desired effect, just not efficiently) and the other is blatant API pollution. Those header files are simply not supposed to be installed, were deliberately not installed for a reason, and will result in even more abuse of the API by users who now don't even necessarily *know* they're doing bad things because they'll see these files sitting in /usr/local/include, where they're supposedly for public consumption. The interfaces in these includes are not guaranteed to stay the same across even point revisions, and I can tell you that John Ousterhout would scream if he knew we were even discussing this as a possibility! :-) I remain convinced: The current method is a bad hack, but your suggestion would be genuinely evil and break lots of rules that would truly get your various appendages whacked if you did it in a commercial software environment.. :-) I would suggest that the correct and proper direction from here is to improve the efficiency of the hack, since it's producing the correct results. To start doing the wrong thing in order to go faster would be a step backward. Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19141.823860686>