Hrvoje Niksic <[EMAIL PROTECTED]> writes:
> "Dan Harkless" <[EMAIL PROTECTED]> writes:
> > > Is it the standard configure caching mechanism, the "(cached)" thing?
> > > I think that can be turned off.
> >
> > Per-check, you mean? We wouldn't want to turn it off for the whole
> > configure run just for the benefit of this check.
>
> Why not? Some programs do exactly that.
Yes, I had noticed that a couple of times, but it didn't occur to me the
decision was made as a simplification step.
> Configure caching is mostly a failed experiment anyway.
Well, maybe not failed, but perhaps outdated...
> It used to be interesting to developers
> who ran configure every now and then on the hardware of the time.
> Today hardware is fast enough that configure runs in a short amount of
> time, so the initial "itch" is no longer there.
Well, as I was just making a bunch of autoconf changes to Wget, I can say
that there is a very noticeable difference between cached and non-cached
even on reasonably-powered hardware, but it's true that the _total_ time
spent is small enough that it probably doesn't matter, at least for a small
package like Wget.
> > A weaker reason not to abort is that someone might want to package
> > wget with their application and always try to configure it
> > --with-ssl.
>
> If we abort on `--with-ssl', there should definitely be a way of
> saying "autodetect SSL". In fact, I think such an autodetect thing
> should be the default.
Good idea.
---------------------------------------------------------------
Dan Harkless | To help prevent SPAM contamination,
GNU Wget co-maintainer | please do not mention this email
http://sunsite.dk/wget/ | address in Usenet posts -- thank you.
