Jacob Meuser wrote:
On Tue, Apr 04, 2006 at 02:20:39PM -0400, Chris Pickett wrote:
presumably, if you are adding stuff, you already know exactly why
you are adding it, exactly what it does, and exactly what the
consequences are. no different than anything else in computing.
I guess this is really it: I don't and can't know; there's just not
enough time to learn everything that my computer does. I fix things
when I find out they are problems. Of course I try to be proactive
about finding problems, primarily by testing early and often, but I'm
not perfect. For example, I didn't know AC_PROG_CC set "-g -O2", even
though I had been using it for a while.
you want simple? nothing is simpler than "default".
sure, if you are releasing _binaries_, you can build with whatever
CFLAGS, since presumably you are also testing the binaries. but for
source distributions, it's best to be conservative.
So, how about providing special flags for known platforms, and a safe
default for unknown platforms? Add to this protection by configure
options so the user really has to want my flags to get them. Is this an
acceptable compromise?
you need stuff like:
# only add -O3 on i386/gcc versions >= 3.0
if USING_GCC
if GCC_VERSION_3
if ARCH_I386
AM_CFLAGS="-O3"
endif
endif
endif
where USING_GCC, GCC_VERSION_3 and ARCH_I386 are being set in tests
in configure. not the greatest example, but hopefully you get the
idea.
Thanks for this example; I can imagine it gets much more complicated
when you start testing out program fragments to see that they don't break.
Shifting the problem onto
the user's shoulders doesn't really do anything for me because they are
the same shoulders!
so just do it in your script that runs configure. trust me, adding
optimization flags is going to annoy people who are trying to build
your software on a platform you don't know about ... and you are
going to have a really hard time trying to help them, since you do
not know that platform!
see, adding these flags makes your job harder!
Yes, I see.
of course, if you are not planning on distributin the software, and
really only _you_ will be the user ... but then why would you be
using autotools in that case?
For now, it's the case that I am the only user; hopefully in the future
that won't be so. Regardless, the Autotools are still useful right now
because they help me develop and build on multiple systems.
There was a confusion here. I meant to say "command-line CFLAGS"
instead of "environment CFLAGS". The Automake manual specifically says
not to clobber whatever the command-line CFLAGS are, to let the user
have the last say, and I was trying to do that by using AM_CFLAGS and
friends.
_but_, AM_CFLAGS will _always_ be added to the compile command.
if you have AM_CFLAGS="-O3 -fomit-frame-pointer", the user _cannot_
remove those without editing the build system. you must check
that AM_CFLAGS is not going to cause problems on any platform your
software will be used on.
How about ./configure CFLAGS="-O2 -fno-omit-frame-pointer"?
But anyway, I think I see your point: don't piss off the user (and
ultimately make my job harder) by forcing them to use my compiler flags.
So, unless they specifically pass --use-my-brain-dead-opt-flags to
configure, they won't see any of them.
The whole irony of this that I actually wanted -O0 but AC_PROG_CC was
killing it. :)
Cheers,
Chris
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
