[PATCH 2/2] Makefile: use curl-config --cflags

[Jeff King <peff@peff.net>]

We add the result of "curl-config --libs" when linking curl programs,
but we never bother calling "curl-config --cflags". Presumably nobody
noticed because:

  - a system libcurl installed into /usr/include/curl wouldn't need any
    flags ("/usr/include" is already in the search path, and the
    #include lines all look <curl/curl.h>, etc).

  - using CURLDIR sets up both the includes and the library path

However, if you prefer CURL_CONFIG to CURLDIR, something simple like:

  make CURL_CONFIG=/path/to/curl-config

doesn't work. We'd link against the libcurl specified by that program,
but not find its header files when compiling.

Let's invoke "curl-config --cflags" similar to the way we do for
"--libs". Note that we'll feed the result into BASIC_CFLAGS. The rest of
the Makefile doesn't distinguish which files need curl support during
compilation and which do not. That should be OK, though. At most this
should be adding a "-I" directive, and this is how CURLDIR already
behaves. And since we follow the immediate-variable pattern from
CURL_LDFLAGS, we won't accidentally invoke curl-config once per
compilation.

Signed-off-by: Jeff King <peff@peff.net>
---
I didn't bother touching configure.ac here, because I don't think it
would do anything useful. The existing configure script will run
"curl-config --libs" to set CURL_LDFLAGS, suppressing the call to
curl-config inside the Makefile. But with the caveat that you can
convince it to pass something besides --libs (though what would be
useful there, I have no idea, and the commit introducing it didn't shed
any light). So following that pattern, at most we'd just be trading a
call during configure time for one inside the Makefile.

What _could_ be useful is if the configure script used curl-config as
part of it's check of whether we have libcurl at all. But it doesn't. We
don't even look for curl-config until we've been able to link against
-lcurl. I have a feeling this could be fixed by reversing the order of
the blocks, but I'm not sure of all of the subtle interactions with
CURLDIR. And I don't care enough about autoconf to puzzle it out. We
certainly aren't making anything worse with this patch.

 Makefile | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 93a8ef3a72..4550bf4a42 100644
--- a/Makefile
+++ b/Makefile
@@ -1359,9 +1359,10 @@ ifdef NO_CURL
 else
 	ifdef CURLDIR
 		# Try "-Wl,-rpath=$(CURLDIR)/$(lib)" in such a case.
-		BASIC_CFLAGS += -I$(CURLDIR)/include
+		CURL_CFLAGS = -I$(CURLDIR)/include
 		CURL_LIBCURL = -L$(CURLDIR)/$(lib) $(CC_LD_DYNPATH)$(CURLDIR)/$(lib)
 	else
+		CURL_CFLAGS =
 		CURL_LIBCURL =
 	endif
 
@@ -1370,6 +1371,11 @@ else
 	endif
 	CURL_LIBCURL += $(CURL_LDFLAGS)
 
+	ifndef CURL_CFLAGS
+		CURL_CFLAGS := $(shell $(CURL_CONFIG) --cflags)
+	endif
+	BASIC_CFLAGS += $(CURL_CFLAGS)
+
 	REMOTE_CURL_PRIMARY = git-remote-http$X
 	REMOTE_CURL_ALIASES = git-remote-https$X git-remote-ftp$X git-remote-ftps$X
 	REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES)
-- 
2.26.0.576.gb87790c3c1