[<prev] [next>] [day] [month] [year] [list]
Date: Fri, 19 Dec 2014 12:57:41 -0500
From: <jfoug@....net>
To: john-dev@...ts.openwall.com
Subject: Re: autoconf
This has been reduced by 15 function probes, and 8 data types. I will look into reduction of header probes, there likely are some that can also go.
NOTE, may of the observed probes come from other macros, such as OMP checking, oSSL checking, etc.
If speed is an issue, then use (and learn the caveats) of the -C caching switch to configure. It will speed things up A LOT. I do feel your pain (but the -C works around this). Cygwin is about as slow as it comes for running the configure script. It can be about a 3-5 minute process. The recent reductions, the 15+8 probes listed here, removing checks for KRB5, etc have made the cygwin configure run quite a bit faster, but it probably can be improved more still.
We do use a lot of what is checked for within configure. Yes, there was some fluff that we never got around to using, but what is being left, IS being used in code to control how the compile goes.
These changed are available 'now' on the bleeding-jumbo git branch, and will be 'officially' available when jumbo-2 is released.
Jim.
---- Solar Designer <solar@...nwall.com> wrote:
> magnum -
>
> I think the current configure script probes for way too many things.
> For many of them, the build should just assume they're present. It'd
> fail otherwise, so no reason to probe for them. For example, why probe
> for strrchr() and snprintf()? I think we don't have alternate code that
> wouldn't use those anyway. Why probe for bzero()? We should simply
> consistently use memset() instead. And so on. Can we halve the number
> of configure tests maybe?
>
> Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
