cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Call for libcurl cmake users/maintainers!

From: Ray Satiro <raysatiro_at_yahoo.com>
Date: Tue, 26 Aug 2014 04:17:46 -0400

On 8/25/2014 4:03 PM, Ray Satiro wrote:
> The conditionals from config-win32 could be rewritten in cmake
> language but then either time one was updated the other probably would
> need to be too. Another idea is some of the defines that are always
> the same not compiler specific or otherwise conditional for windows
> could go in a separate file that could be included by both cmake's
> curl_config.h and config-win32.h, but that kind of defeats the point
> of cmake I guess. For example you could test recvfrom in cmake but
> you're fairly certain it's going to be available so in config-win32 it
> is always on and that could go in a file shared by both. Or just
> always include config-win32 for (WIN32) although again this idea is
> defeating the point of cmake. I'll try adding a USE_WIN32_LARGE_FILES
> conditional to CMakeLists.txt tonight.

I made some changes to CMakeLists.txt to get curl_config.h output closer
to what's in config-win32.h. There are a few things I couldn't resolve
if anyone can pick up from here:

There is some inconsistency with the _TYPE_ARG macros, it looks like
most expect the asterisk in the define but RECVFROM_TYPE_ARG macros you
are expected to not have the asterisk when necessary because it's
already in the prototype. For example look at curl_setup_once.h:229:
(RECVFROM_TYPE_ARG2 *)(b)
I accounted for that but it's confusing.

I did an override for all the _ARG macros with their actual type
information. There is detection code in CMake/OtherTests.cmake but I
noticed for me at least it was detecting argument types that were not
the same as what is on msdn and in config-win32. Like size_t instead of
int. Or int instead of SOCKET (which is a pointer in VS2010). I didn't
have time to diagnose the detection code so I just put in overrides for
all the ARG types so that they are correct and put a TODO in a comment.

I didn't add HAVE_GETADDRINFO_THREADSAFE. Is it always thread safe? I
read this post which had me concerned.
http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/2adc8097-05e6-458e-aad2-4e905fa86d01

I didn't add the machine string (define OS) for the version information.
It just says "Windows". See the bottom of config-win32.h for how it can
be implemented.

I have setvbuf (VS2010) but for some reason I couldn't figure out it's
not detected so HAVE_SETVBUF is off.

Despite getting OpenSSL working (I had to make some directory junctions
to get cmake's openssl detection module detecting it) these macros
weren't defined: HAVE_RAND_SCREEN, HAVE_RAND_STATUS,
HAVE_CRYPTO_CLEANUP_ALL_EX_DATA. I have all of those functions and cmake
is getting the headers and libraries properly and does testing for them
and openssl is on so I don't know why that is. Going to https websites
works anyway but I'm not sure of any security issues here.

I built with OpenSSL 1.0.1 and IPv6 options on master branch commit
ee40b68 20140808. I don't have IPv6 setup on this computer so I didn't
test that.
curl 7.38.0-DEV (Windows) libcurl/7.38.0-DEV OpenSSL/1.0.1i
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s
rtsp smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile NTLM SSL

I didn't test LDAP or libssh or any cmake options other than IPv6 and
OpenSSL.

If anyone wants to pursue cmake support for windows the above stuff
would be a good place to start.

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

Received on 2014-08-26