On Mon, Aug 5, 2013, Daniel Stenberg wrote:

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

In some cases tolerating funny flag definitions may be absolutely
harmless, while in others these errors will be caught further on when
user does not get what he expected or build simply fails. Obviously
these two cases are not the ones that worry me. My worries are
directed towards those funny flag definitions that allow configure to
apparently succeed but that actually generates erroneous curl_config.h
definitions without the user being aware of it.

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

Of course Autotools have not invented them. But Autotools use them in
a specific way, and as such any project using Autotools to generate
configure script and any user of a configure script generated using
Autotools is forced to honor Autotools usage with whatever limitation
or benefit this represents.

For example, defining a preprocessor flag in CFLAGS instead of doing
so in CPPFLAGS causes most notably the following issues: Preprocessor
checks taking place in configure script will not use the flag so the
output of such checks might be invalid (generating potentially invalid
config.h data). Additionally the flag will be provided to the linker
in configure script linking checks and configure generated makefiles.
Given gcc and gnu ld increasing intolerance of invalid options this
would simply result in linking failures with recent tools.

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

Yep, if the misuse triggers something which translates in the
inability to build the project, the user will further investigate,
otherwise it may go unnoticed and final build may be valid or not even
if the build finalizes.

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

In this FreeBSD libcurl port specific case I agree that it is a
harmless setting. But only due to -DLDAP_DEPRECATED not being needed
for anything. If the definition was actually needed things would be
quite different.

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

Ok, now I can see where the issue is coming from...

http://svnweb.freebsd.org/ports/head/ftp/curl/Makefile/ indirectly
includes http://svnweb.freebsd.org/ports/head/Mk/bsd.ldap.mk/ which is
unconditionally appending -DLDAP_DEPRECATED to CFLAGS before running
configure script.

It is a bit surprising that
http://svnweb.freebsd.org/ports/head/ftp/curl/Makefile/ is careful
enough as to properly use CPPFLAGS for -Istuff and LDFLAGS for -Lstuff
when doing an ldap, openssl or spnego libcurl enabled build and on the
other hand it currently gets -DLDAP_DEPRECATED stuffed into CFLAGS
from bsd.ldap.mk for ldap enabled builds.

As a matter of fact there are a couple of bug reports related with
this in FreeBSD's bug tracker,
http://www.freebsd.org/cgi/query-pr.cgi?pr=177401 and
http://www.freebsd.org/cgi/query-pr.cgi?pr=180492

So yes, until FreeBSD's ports/head/ftp/curl/Makefile and/or
ports/head/Mk/bsd.ldap.mk get fixed FreeBSD will be misusing CFLAGS,
independently of libcurl's configure script tolerating the misuse or
not. Not tolerating the misuse has uncovered the issue and knowing
that it exists may help FreeBSD's libcurl and/or OpenLDAP port to
decide what to do about it.

Given that this is an issue that FreeBSD's libcurl port is introducing
I could argue that it should be FreeBSD's libcurl port the one that
needs a workaround until they do a proper fix, given that they already
patch libcurl's original configure script for other stuff
http://svnweb.freebsd.org/ports/head/ftp/curl/files/patch-configure/
the port could equally patch it for the issue the OpenLDAP port is
introducing into libcurl's port.

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

Killing previously existing usage in current _XC_PROG_CC makes it
currently irrelevant in libcurl's source code repository, the safety
it was providing has now disappeared from libcurl's configure script,
easing clunky builds again.

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