On Wed, 11 Aug 1999 17:16:01 +0100, Duncan Simpson wrote:
>> On 11 Aug 1999 15:11:23 +0200, Lars Gullik Bj°nnes wrote:
>>
>>This solution would produce elegant source code, if and only if
>>configure runs successfully. If not, you are left on you own.
>>
>Actually it is not hyper-impossible to manually do the substitutions yourself with
>your favorite text editor. Doing so sucks but is pretty trivial (given you know which
>header applies, what the answer to the comment tells you the symbol in config.h.in
>refers too, etc).
Well, yes. Only remembering poor me sitting confused in front of
AIX-terminal, people of computing service department (stressed as
always) shouting: "Don't you, don't even think to use gcc or autoconf
here". Those things are really no fun ;-)
>
>GNU autoconf output is extremely portable too and works on all known unicies that are
>vaguely modern, probably including most pre-POSIX systems, with the possible
>exception of the M$ POSIX stuff (the vibes are this works only sometimes).
Provided, box isn't too modern. New vendor patches (or new glibc) break
configure tests, 'till someone is so kind as to provide the fix (which
in turn breaks other tests, elsewhere, etc.)
Well, at least here they told me:
Never even think about gcc or auto*xy on (not so good) old sgi
xl-8 (irix), ibm rs6000/580 (aix), hp 9000/755 (hp-ux), or even on
stone-age cd 4360 (ep/ix). At least there, you're stuck with native
compilers.
All in all, it's as portable as people ported it to their respective
boxes, I think... Certainly a great deal of effort has been invested
there, so that it is well reasonable to profit from this. Only I'd like
to suggest not to depend on it, where you can easily (and more or less
elegantly) live without.
>My shell script addition uses no exotic or new, e.g. introduced by POSIX, features of
>test or shell script. The cygnus cygwin stuff supports configure that works 100%. no
>suprise.
Well, they are the maintainers and have an commercial interest, to sell
their cygwin; no surprise.
And emx has a long history and in several parts an old-fashioned
interface, a bit like SYSVr2/3.6/usg. No surprise: Eberhard Mattes
dates back parts of his modules copyrights (MIT-style C lib licence,
tools, etc.) to 1986, most 1990. For speed this won't change too soon
to slower interfaces like glibc. Several people had to invest much work
to make it at least work in most parts in this environment.
>
>As for your solution goes just think maintance and understand why I think my methods
>are superior. Unless you are very careful you have massive screeds of condition
>#include lines with gotchas for any new system, which basically negates most of the
>effectiveness of GNU autoconf (things used to use a similar strategy to cope with
>system dependencies and it sucks).
Well, better only use system specific support libraries and separate
headers. I don't like like to clutter function bodies or actual C++,
either.
Cheers,
Arnd
PS:
As it seems, uni throws central power supply on garbage pile, so I'll
be off-line for some time.
