cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: gcc warnings in non-debug builds

From: Yang Tse <yangsita_at_gmail.com>
Date: Sun, 5 Oct 2008 04:37:54 +0200

Hi Daniel both ;-) et all

Someone should have twisted my fingers for writing such an intrusive
design as the one I've posted in my previous message in this thread
for the --enable/disable-optimize configure option.

I think that this other 'concept', sketched below this lines, is less
intrusive and more friendly with traditional use of CFLAGS.

--disable-optimize option given to configure:

We will handle this as a request to disable compiler optimizations if possible.
This will be possible if the compiler is known, in this case CFLAGS
and CPPFLAGS will be overridden, otherwise user will be warned and
CFLAGS and CPPFLAGS not changed.

--enable-optimize option given to configure:

We will handle this as a request to enable compiler optimizations if possible.
This will be possible if the compiler is known, in this case CFLAGS
and CPPFLAGS will be overridden, otherwise user will be warned and
CFLAGS and CPPFLAGS not changed.

Neither of --disable-optimize nor --enable-optimize option given to configure:

Initially we will handle this as a a request contrary to configure's
setting for --enable-debug. IOW, initially, for debug-enabled builds
this will be handled as a request to disable optimizations if
possible, and for debug-disabled builds this will be handled initially
as a request to enable optimizations if possible.

It is a requisite that the compiler is known for this to be possible.
Not only due to the potential need to introduce compiler-specific
optimization flags, but also due to the fact that CFLAGS and CPPFLAGS
must be checked for already pre-existing optimizer flags.

So, finally, if the compiler is known and CFLAGS and CPPFLAGS do not
have any optimizer flag the request will be honored, in any other case
the request can not be honored.

IOW, existing optimizer flags defined in CFLAGS or CPPFLAGS will
always take precedence over any initial assumption when
--disable-optimize nor --enable-optimize are specified.

I think this behaviour makes more sense than the one I've described October 03.

No need for the --enable-optimize arguments at all, nor the 'magic' argument.

Comments?

-- 
-=[Yang]=-
Received on 2008-10-05