Following this discussion with detached interest, not much to offer here, except...
> ...autoconf fills in the corner cases the original author never > thought about and certainly doesn't want to. One thing I learned too late was, as I thought of it, the difference between context-based and attribute-based configuration and build. libJudy, like much HP software that ran almost exclusively on HPUX, was context-based. So you'd see #ifdefs like: "#ifdef HPUX_90" and that was considered plenty portable within our "tribe". Attribute-based means not knowing ahead of time where you are going to try to run, only what features you care about being present or absent. (For a really good time, one time I built Perl from sources, and could not BELIEVE the hundreds of attributes it cared about and checked on.) I think it's true that real portability cares about attributes not preconceived notions of context. But also true that autoconf, etc, while powerful, were inelegantly hacked together (or so it appeared to me), very hard to learn and use. After recognizing myself doing it, I coined the phrase "software macho" to refer to cases where a tool creator's response to complaints is, "it works for ME, what's YOUR problem?" Or worse, "if you don't like it, don't use it!" About as far from user-friendly or user-adoring as you can get. > It is pretty vacuous and trivially true to say "the solution to > autoconf is to live in a world where autoconf isn't needed" because > that is not the world we all live in... Yeah, wouldn't it be nice? But if there was every one Revealed Truth, why would for example every major world religion have so many sects and dialects? :-) Just rambling here, but another revealed truth for me over the years was how hardly anyone ever took the time to get their code "right" to start with -- actually that's impossible -- but they considered so much of it as prototypical throw-away trials, yet never had time to go back and refactor and improve them to high quality before losing control of them. (I lectured a lot of people on the notion that NOTHING they coded or documented should EVER be considered a throw-away, with rare exceptions still carefully labeled as such!) It's an interesting paradox, you can't really front-load the software engineering process (HP used to try, abusing hardware ERS/IRS models to design software); but once something kind-of works, who has time (or is allowed by management) to spend more time ($$) on it to make it solid? I got yelled at a lot for what I later realized was repeated refactoring. Fortunately I typed fast and my overall level of output was high. :-) Cheers, Alan Silverstein ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk _______________________________________________ Judy-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/judy-devel
