In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote:
.
.
.
>Anyway, checking the system name is the wrong way to build portable
>programs. For one thing, as you've discovered, new systems won't work
>properly. For another, upgrades to existing systems may break things
>as well.
>
>What you should do instead is check on how to use the features you
>want. If you watch a typical autoconf script, you'll see it groveling
>through libraries, include files, and various directories looking for
>subroutines, defines and commands. That's the idea, but without
>knowing which features you're looking for, I can't say how you would
>check for them.
>
>This takes more time to write, but results in more robust code. For
>instance, if some distribution changes one of the features to mimic a
>"better" distribution that you already support, instead of your script
>breaking, it'll just work. This is much better than having to teach
>your script how to distinguish between versions of distributions.
.
.
.
Not for me.
Well, not absolutely. I have a load of respect for you, Mike, and there
certainly are amazing edifices built on autoconf. Also, I think it's an
important part of our engineering to understand the principle of groveling
around interrogating capabilities; among other things, it's good practice
for duck typing and idiomatic Python exception style. I'm very
uncomfortable, though, with an assertion that reliance on a fixed table of
attributes is always wrong.
Briefly, use of autoconf is FAR from a guarantee that everything works
right when starting with a new flavor.
--
http://mail.python.org/mailman/listinfo/python-list
