Re: new vs old autoconf / Re: checking for non-standard headers

[Guido Draheim]

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-