@lygstate, thanks for your PR! By analyzing the annotation information on this pull request, we identified @billhoffman, @Sukender and @Lekensteyn to be potential reviewers

@lygstate Could you please describe what problem you trying to solve?

@snikulov I was trying to include libcurl in another CMake based system.
For example:

  add_subdirectory(zlib)



  set(BUILD_TESTING OFF CACHE BOOL "Disable curl tests")
  set(ZLIB_FOUND ON)
  set(ZLIB_INCLUDE_DIRS ${CMAKE_CURRENT_SOURCE_DIR}/zlib ${CMAKE_CURRENT_BINARY_DIR}/zlib)
  set(ZLIB_LIBRARIES zlibstatic)
  add_subdirectory(curl)
  target_include_directories(libcurl
    PUBLIC
    ${CMAKE_CURRENT_SOURCE_DIR}/curl/include
    ${CURL_BINARY_DIR}/include/curl
  )

So I could link zlib into libcurl as static library. And building zlib directly from souce without need the pre-build binaries

@lygstate I don't think that adding more checks and conditions into curl's CMakeLists.txt for your personal reasons is a good idea, sorry. It is complicated enough already.
In addition, you trying to put more commits within single PR.
It is also bad idea, IMHO.

What is wrong with the call to check_library_exists_concat?

@jay it's second unrelated to zlib change, which is not described in PR.

it's second unrelated to zlib change, which is not described in PR.

Possibly but I still want to know why he did it. As far as the zlib change goes I don't know enough about cmake build system to know whether this is a typical thing to want. It seems like he wants to override our settings with his own. Is that typical in cmake?

@jay when I trying to compiling under win64 it's failed, that's why I am not calling to check_library_exists_concat directly

@jay when I trying to compiling under win64 it's failed, that's why I am not calling to check_library_exists_concat directly

How did it fail, can you give us any more information? I can't see why it would fail.

@lygstate your fix for the crypt32 issue has landed in 2bbed9c, thanks.

No response for months. Dead.