On Sun, Aug 4, 2013 at 10:28 AM, GitHub <noreply_at_github.com> wrote:

> Commit: 6b27703b5f525eccdc0a8409f51de8595c75132a
> https://github.com/bagder/curl/commit/6b27703b5f525eccdc0a8409f51de8595c75132a
> Author: Daniel Stenberg <daniel_at_haxx.se>
> Date: 2013-08-04 (Sun, 04 Aug 2013)
>
> Changed paths:
> M m4/xc-val-flgs.m4
>
> Log Message:
> -----------
> configure: don't error out on variable confusions, just warn

Hi Daniel,

I hope this doesn't sound harsh, as it isn't my intention...

Commit 6b27703b simply subverts purpose of XC_CHECK_USER_FLAGS macro
given that it is documented to halt configure script execution upon
detected errors. Meanwhile, macro XC_CHECK_BUILD_FLAGS performs same
checks but allows configure script to continue execution even upon
detected errors.

Usage of XC_CHECK_USER_FLAGS with its halting behavior from within
_XC_PROG_CC was fully intentional in order to save poor souls which
are not fully aware that when using autotools there are some basic
autotool 'rules' that should be observed as otherwise quite funny
results might be achieved.

As you already know, the range of users that use libcurl's configure
script vary from the very casual person who knows nearly nothing about
using a compiler nor a shell script to the very expert people capable
of fixing nearly everything by themselves.

Those using CFLAGS, CPPFLAGS, LDFLAGS and LIBS as intended by the
autoconf and automake tools will not find problems related with
misusing these. Those that misuse these flags may encounter harmless
situations or very fatal situations and anything in between depending
on the kind and specific misuse they are performing.

Some of the most dreadful error messages one may get when running a
configure script are those that say things such as 'can not create
executables' or 'compiler does not work' when the configure script is
performing initial compiler checks triggered by code inserted quite
early into configure script by either autoconf or automake.

Diagnosing what is happening is a real pain, specially when the error
is triggered due to a flag misuse which leaves no actual trace in
config.log that could be used to pinpoint the issue.

On the other hand if XC_CHECK_USER_FLAGS with its halting behavior is
run before AC_PROG_CC (such as it is currently done in _XC_PROG_CC)
configure script is capable of doing some minimal sanity checks on
flags usage before the compiler checks are actually performed,
avoiding to a big degree fatal messages that would be triggered as
soon as compiler checks are performed.

Existing sanity checks in XC_CHECK_USER_FLAGS are not perfect, in the
sense that it is not capable of detecting lots of misuses, but it
catches some common pitfalls which might be an indication that some
other serious issue are also involved.

The reason for using XC_CHECK_USER_FLAGS with its halting behavior in
_XC_PROG_CC is simple. Over the years we have seen that very few care
about warnings emitted by configure scripts. While on the other hand
libcurl project does really care about trying to ease build process
for nearly everyone regardless of their expertise, and specially that
if configure script fully runs to the end they will actually be
capable of building a valid library.

Given that all this has been triggered by the FreeBSD 'port' of
libcurl lets use it as an example of what seems a funny 'bug report'.
AFAIK FreeBSD ports tree is built and matched for specific FreeBSD
versions and specific versions of whatever they include as a 'port'.

So next FreeBSD released 'port' of libcurl will for sure build
successfully for the FreeBSD version they release it. No matter what
libcurl project does. Currently it seems they have jumped from 7.24 to
7.31. It also seems that files in
http://svnweb.freebsd.org/ports/head/ftp/curl/ do not define
LDAP_DEPRECATED anywhere. So assuming the report is valid, where on
earth is that definition coming from?

In this case it is an innocuous preprocessor definition not needed by
libcurl, But it could have been whatever other flags coming from no
one knows where that could triggers all kind of badness. Wasn't
FreeBSD ports build servers compromised back at the end of 2012?

Hmmmm

Back to our stuff...

I disagree with changing existing behavior of XC_CHECK_USER_FLAGS.
Please revert commit 6b27703b.

I also disagree with allowing compiler checks to take place upon
detection of autoconf and automake non conformant flags. But if you
really want this non-halting behavior it is better to modify macro
_XC_PROG_CC in xc-cc-check.m4 line #62 so that instead of
AC_REQUIRE'ing XC_CHECK_USER_FLAGS it AC_REQUIRE's
XC_CHECK_BUILD_FLAGS.

Thanks,

-- 
-=[Yang]=-
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html