On Sun, Aug 4, 2013 at 10:28 AM, GitHub <nore...@github.com> wrote: > Commit: 6b27703b5f525eccdc0a8409f51de8595c75132a > > https://github.com/bagder/curl/commit/6b27703b5f525eccdc0a8409f51de8595c75132a > Author: Daniel Stenberg <dan...@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