Thomas E. Dickey wrote:
On Tue, 12 Aug 2003, Guido Draheim wrote:
Thomas E. Dickey wrote:
On Tue, 12 Aug 2003, Guido Draheim wrote:
of another file. In all other cases, I'm quite fine... what features are overdue by your records, Thomas?
I suppose you could look at the cvs version and answer your own question. I recall seeing a half-dozen serious bugs reported - and fixed - since 2.57, making the difference at least as much as from 2.54 to 2.57. (2.55 & 2.56 were blunders, of course - read the changelog).
Hmm, I might wonder what your "serious bugs" are, it looks like a lot of those are portability fixes, which is not quite the same as serious problems
autoconf is supposed to be portable (if you think another consideration is more important, that's your opinion, but I don't have any use for it).
No doubt about that but may be I have a different level of expectation about what portability the autoconf gives me. There was a time that software makes were shipping Makefile.linux, Makefile.solaris, Makefile.hpux, Makefile.freebsd and such and also asking the final recipient to edit the first few lines to let CC et al point to the location of their choice of compilers. All these Makefiles can be collapsed however into just one Makefile.in that gets `configured`, originally leading to the very same result that was present in the architecture-specific Makefile before the introduction of `configure` services. By no way, such `configure` script must be made up by autoconf, in fact there are a number of succesful software packages that use `configure`s not made from autoconf.
In fact, it does not quite matter since bringing the software to a new platform may in fact lead to yet another round of `portability fixes`, checking yet again for yet another header file or system feature to be present or emulating it within the sources adding somewhere a -Define. That's what my question was for, repeating, whether autoconf has contained (portability) bugs that did hurt _your_ platforms for which _your_ software gets configured for. Personally, I don't expect `configure`d to run snappy on each braindead platform in the world.
Such a thing would be nice of course, and autoconf can help with that asking for `test features not platforms` since originally the `configure` script would run `config.guess` and make up a big `case` switch around "$host" and setting variables to be ac_subst`ed into the Makefile.in. Yes, one can still do it with autoconf but its better to test a feature and add subst-s and define-s according to it without relying on the "$host" value, and hopefully, and only by mere luck, these are all the features that makes the software configure-n-go on a platform not originally tested on, and ported to.
However, let's not cover the fact that quite some autoconf macros do rely themselves on the "$host" value or results of other tests introduced specifically for some weird host platform. Simply, to hide problems of these platforms, and provide a test service in such a way that the macro user does not need to care. That's nice so I can just pluck a test by characterization and it's always not nice if the macro fails to cover up portability issues.
It's just I didn't meet such problems lately, possibly needing to add some case `$host` around the macro like in the ol' days. And since there were no problems like these, I don't need to ask for a quick release of the autoconf helpers. And for me it's just that, a helpful tool with a number of macros that cover up $host or $CC specifica.
Perhaps that's a result of my own works were I had been needing to write up a number shell-sequences testing for $host or $CC specific setups in my scripts - until I started to wrap them up in ac-macros themselves and reuse them across the projects I run. My configure scripts contain quite a number of those extra ac-macros, often the number of AC/AM macros is less then 50%.
In the AC-Archive you can find quite a number of those extra macros that go beyond the services of autoconf. It happens to be better to pick up a macro from somewhere else than starting to write up your own shell-sequences to test $host or $CC features. With the AC-Archive however the macros are prepared for even fewer $host or $CC combinations, and their macro authors are usually open to add patches from someone porting to yet another platform.
'nuff said, have a great day, and what are your macros that I can add to the AC-Archive? cheers, -- guido http://AC-Archive.sf.net GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X-
