2008/10/3, Dan Fandrich wrote:
> On Fri, Oct 03, 2008 at 01:15:09AM +0200, Yang Tse wrote:
> > So probably another new option such as --enable-optimize[=FLAGS] or
> > something similar should be considered. I think I'll go this route.
> Why not just use the existing CFLAGS mechanism? There doesn't have
> to be a configure option for absolutely everything. Maybe just skip adding
> an optimize flag if CFLAGS is non-empty.
Having an --enable-optimize option allows to make its settings more
independent of the --enable-debug option. Up to and including libcurl
7.19.0 have them highly coupled.
I agree that possibly it would be desirable to only have to use the
user provided CFLAGS. But inspection of the CFLAGS contents will be
required, as otherwise we would be falling in the same error as
autoconf's AC_PROG_CC. Just because CFLAGS is set it doesn't mean that
it holds debug or optimizer flags.
Before going on with the CFLAGS 'issue' let me introduce some other points.
Decoupling of the optimization flags and the --enable-debug option
should be done for the following reason:
Up to and including libcurl 7.19.0 --enable-debug implies that the
optimizer flags are stripped from CFLAGS, This leaves the desirable
setting to properly debug code using gdb. But on the other hand it
leaves the test harness and autobuilds without precious information
relative to compiler warnings on things as simple as the use of
So it seems that the proper setting for debug-enabled builds would be
'-g -O0' fro interactive debugging, and '-g -O2' for testcurl.pl
With that in mind it comes more clear that testcurl.pl will have to
instruct configure to use '-g -O2' for all builds disregarding user
provided optimization flags from CFLAGS, specially now that non-debug
autobuilds are also capable of showing those warnings.
If someone looks at the autobuilds logs. please remember that the ones
which have the 'traditional' settings are those dated 2008-09-30 and
For example autobuild "Red Hat 7.2 Linux 2.4 i686 gcc 2.96 FTP only"
which is a debug-enabled one on 2008-09-30 due to optimizer flag
stripping was simply using '-g' and no warning was shown. But on
2008-10-02 '-g -O2' was used and some warnings surfaced that were been
hidden by the fact of not using -O2.
And there are other cases in which enabling warnings for
debug-disabled builds have uncovered other warnings.
Let's see if i can describe with words how a possible
--enable-optimize --disable-optimize could work.
--disable-optimize option given to configure. Strip optimizer flags
from CFLAGS and CPPFLAGS and let configure introduce '-O0' into
--enable-optimize option given to configure with no arguments. Strip
optimizer flags from CFLAGS and CPPFLAGS and let configure introduce
'-O2' into CFLAGS.
--enable-optimize option given to configure with a user provided
argument. Strip optimizer flags from CFLAGS and CPPFLAGS and let
configure introduce the user provided argument into CFLAGS
--enable-optimize option given to configure with a special argument,
that could be spelled 'cflags' in lowercase. Strip optimizer flags
from CPPFLAGS and, prevent configure from stripping optimizer flags
Neither of --disable-optimize nor --enable-optimize option given to
configure. In this case configure should use the contrary setting of
configure's debug option. IOW default of '-O0' for --enable-debug, and
default of '-O2' or --disable-debug.
I'm frankly open to new ideas, of course.
Received on 2008-10-03