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
