On Tue, Feb 06, 2007 at 02:00:58PM -0500, Glenn Fowler wrote: > I believe one of the attractions of bringing ksh93+ast into ON is > the that it does configure for many systems > doing so produces executables that behave in a similar way, > modulo system specific features, on all systems
And as I've pointed out elsewhere, autoconfiguration is the exact wrong thing to bring into ON. First, it's inherently illogical - ON is by definition always a part of OpenSolaris and never a part of any other OS. That means that all the autoconfiguration functionality itself is immediately and forever dead code. Second, any changes to the code that are required to support either autoconfiguration or characteristics of other operating systems need to be evaluated without regard for their merits outside of ON; in nearly all cases they reduce readability, clarity, and maintainability. ON (and OpenSolaris in general) offers a lot of simplifying assumptions that can improve code quality. The issue at hand is a perfect example of this. Third, autoconfiguration at compile time often encodes the assumption that buildtime and runtime hosts are identical, which is usually wrong. This can lead to difficult-to-debug problems. Fourth, and most devastating to my way of thinking, it can and does lead to overlooking the impact of changes elsewhere in the codebase that affect (or should affect but don't) the autoconfigured component. It also encourages laziness and sloppiness. If, for example, someone makes a change that removes a Consolidation Private function from libc, a component that relies on that function should in turn fail to build, alerting the engineer to the need to replace calls to the function with some newer alternative (or perhaps that the function ought not be removed after all). Autoconfiguration papers over this by either substituting its own (probably inferior) implementation or disabling the use of the newly-removed feature. This is, to say the least, unexpected and undesirable. It's fine for AT&T to offer components that autoconfigure if that's what their customers want. There's some value in being able to get some kind of hopefully useful binary out of a pile of source code on HPUX, Solaris, GNU/Linux, and ConvexOS. But that's not a problem we have. This is ON. We know what the environment offers, and we know what interfaces are available to us. And if those change in a way we don't expect, we want to know *before* a user complains about it. Dead code has no place in ON, and workarounds for bugs and incompatibilities in other operating systems should be present only when needed to interoperate with those systems - not to build on or for them. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!"
