cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: [bagder/curl] 6b2770: configure: don't error out on variable confusions, ...

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Mon, 5 Aug 2013 09:34:00 +0200 (CEST)

On Mon, 5 Aug 2013, Yang Tse wrote:

> 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.

First let me motivate my reasoning for changing the behavior:

I don't think we should be strict pedants that point out _possible_ flaws and
errors out on them. I'd rather have us point out the possible problems,
clearly warn about them and then let the script continue and possibly still
work. Or not. The user has been warned.

Autotools have not defined the meaning of these variables (CFLAGS, CPPFLAGS,
LDFLAGS etc) from the start. They were used by make and compilers even before
autotools entered the scene. The "no -D in CFLAGS" rule is not universal.

People rarely care about warnings anywhere indeed so I realize it may then
just delay the failure to become something much more strange-looking later in
the build process. However, in this case I think that the check is too strict
and in many cases will prevent a build from otherwise succeeding. Ie the
balance between failing due to an innocent setting compared to allow a setting
that will fail the build is a bit too strong to the first for my taste.

> 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?

(For users who didn't see it, this particular FreeBSD build problem is here:
https://sourceforge.net/p/curl/bugs/1261/)

The user "Madam Smokey" says it comes from /usr/ports/Mk/bsd.ldap.mk which
sounds like a global setting so it is probably meant to cover multiple builds.
So doing some speculations, it may even _have to_ be in CFLAGS for another
package to build.

> 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.

Aha - will do! Thanks, will push that change right now.

Is there a good reason for having both XC_CHECK_USER_FLAGS and
XC_CHECK_BUILD_FLAGS in the m4 file when we only use one of them?

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Received on 2013-08-05