> From: Aaron Bannert [mailto:[EMAIL PROTECTED] > > On Mon, Jun 10, 2002 at 06:51:13PM -0000, [EMAIL PROTECTED] wrote: > > rbb 2002/06/10 11:51:13 > > > > Modified: . configure.in > > Log: > > It helps to document the actual option. :-) > > > > Revision Changes Path > > 1.452 +1 -1 apr/configure.in > > > > Index: configure.in > > =================================================================== > > RCS file: /home/cvs/apr/configure.in,v > > retrieving revision 1.451 > > retrieving revision 1.452 > > diff -u -r1.451 -r1.452 > > --- configure.in 9 Jun 2002 18:50:47 -0000 1.451 > > +++ configure.in 10 Jun 2002 18:51:13 -0000 1.452 > > @@ -310,7 +310,7 @@ > > user_disabled_optimized_atomics=0 > > > > AC_ARG_ENABLE(atomics, > > - [ --disable-optimized-atomics Turn off optimized atomic code], > > + [ --disable-atomics Turn off optimized atomic code], > > [ if test "$enableval" = "no"; then > > user_disabled_optimized_atomics=1 > > fi ] ) > > Hmm...this snafu would have been my fault, but you've reversed my > name changes. The option doesn't actually disable atomics, it just > doesn't let solaris support atomics in a way that would break > binary compatibility across sparc architectures. Let's either provide > an option that actually disables atomics, or rename this one (in > a non-broken way).
I don't really care what we do, or what the option is. I spent a half-day trying to disable the optimized atomic code, and it wasn't until I started really digging into it that I realized that it was just a question of documentation. Ryan
