V3 Configury

Phil Edwards pedwards@disaster.jaj.com
Tue Jan 23 08:03:00 GMT 2001


On Mon, Jan 22, 2001 at 09:10:17PM -0800, Mark Mitchell wrote:
> 
> More to the point, are their systems that really have acosf, and
> asinf, but not atanf?  I bet not.
[...]
> I'm going to group these functions into bigger amalgamations and just
> produce all-or-nothing results for the whole amalgamation.  That
> should reduce the per-function cost substantially.

Like Gaby says, no bet.  :-)  The current, er, well, current-before-
you-applied-the-patch, design was largely motivated by the surprises
we kept receiving every time the math sublibrary got ported to a new
platform, or even a new point-revision of an OS.  Minor changes in the
visibility or signature of some trig function that you haven't heard
of since trig class in high school, etc, were tripping us up.

Our fear is that "grouping" the tests will set us up for more of these
surprises.


> Also, <ctype> detection alone takes a long time (over a minute) to
> work out.  Why are we doing this with autoconf (in a rather hacky way,
> involving checking for funny symbols in ctype.h) rather than using
> configure.target, like we do for other obscure properties on the
> target?  I'm going to change that too.

The autoconf tests predate the existence of config.target by a long time.
Moving them seems safe to me.


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.


More information about the Libstdc++ mailing list