neovim/cmake.deps/cmake/BuildLibiconv.cmake

if(MSVC)
  if(USE_EXISTING_SRC_DIR)
    unset(LIBICONV_URL)
  endif()
  ExternalProject_Add(libiconv
    URL ${LIBICONV_URL}
    URL_HASH SHA256=${LIBICONV_SHA256}
    DOWNLOAD_NO_PROGRESS TRUE
    DOWNLOAD_DIR ${DEPS_DOWNLOAD_DIR}/libiconv
    PATCH_COMMAND ${CMAKE_COMMAND} -E copy
      ${CMAKE_CURRENT_SOURCE_DIR}/cmake/LibiconvCMakeLists.txt
      ${DEPS_BUILD_DIR}/src/libiconv/CMakeLists.txt
    CMAKE_ARGS
      -DCMAKE_INSTALL_PREFIX=${DEPS_INSTALL_DIR}
      ${BUILD_TYPE_STRING}
      -DCMAKE_GENERATOR=${CMAKE_GENERATOR}
      -DCMAKE_GENERATOR_PLATFORM=${CMAKE_GENERATOR_PLATFORM})
else()
  message(FATAL_ERROR "Trying to build libiconv in an unsupported system ${CMAKE_SYSTEM_NAME}/${CMAKE_C_COMPILER_ID}")
endif()

list(APPEND THIRD_PARTY_DEPS libiconv)
build/msvc: Add libiconv to bundled dependencies 2018-06-06 18:39:17 -07:00			`if(MSVC)`
build(deps): restore support for USE_EXISTING_SRC_DIR (#20491) 59d5f692f removed cmake.deps/cmake/DownloadAndExtractFile.cmake and support for USE_EXISTING_SRC_DIR. The Ubuntu nightly PPA still relies on USE_EXISTING_SRC_DIR functionality since it can't access the network during the build. Supplying an empty value for ExternalProject_Add()'s URL value appears to provide the needed mechanism to avoid re-downloading when the sources are already present. This is undocumented behavior, though, so it may break in the future. Now, if USE_EXISTING_SRC_DIR is set, the ExternalProject's URL variable is unset, preventing the download and erroring out if the source doesn't actually exist. 2022-10-06 06:14:38 -07:00			`if(USE_EXISTING_SRC_DIR)`
			`unset(LIBICONV_URL)`
			`endif()`
build/msvc: Add libiconv to bundled dependencies 2018-06-06 18:39:17 -07:00			`ExternalProject_Add(libiconv`
			`URL ${LIBICONV_URL}`
build: rely on builtin cmake downloading rather than custom script DownloadAndExtractFile.cmake was initially introduced as a workaround to avoid the massive amounts of logs generated by the download progress. This is not a problem anymore as ExternalProject_Add has had the DOWNLOAD_NO_PROGRESS option since cmake version 3.1. 2022-09-29 12:46:14 -07:00			`URL_HASH SHA256=${LIBICONV_SHA256}`
			`DOWNLOAD_NO_PROGRESS TRUE`
build/msvc: Add libiconv to bundled dependencies 2018-06-06 18:39:17 -07:00			`DOWNLOAD_DIR ${DEPS_DOWNLOAD_DIR}/libiconv`
build: rely on default cmake installation if possible The default cmake installation process for dependencies that use cmake on all platforms is in general more robust and less verbose, so we rely on that if possible. 2022-10-21 02:37:19 -07:00			`PATCH_COMMAND ${CMAKE_COMMAND} -E copy`
build/msvc: Add libiconv to bundled dependencies 2018-06-06 18:39:17 -07:00			`${CMAKE_CURRENT_SOURCE_DIR}/cmake/LibiconvCMakeLists.txt`
build: rely on default cmake installation if possible The default cmake installation process for dependencies that use cmake on all platforms is in general more robust and less verbose, so we rely on that if possible. 2022-10-21 02:37:19 -07:00			`${DEPS_BUILD_DIR}/src/libiconv/CMakeLists.txt`
			`CMAKE_ARGS`
			`-DCMAKE_INSTALL_PREFIX=${DEPS_INSTALL_DIR}`
			`${BUILD_TYPE_STRING}`
			`-DCMAKE_GENERATOR=${CMAKE_GENERATOR}`
			`-DCMAKE_GENERATOR_PLATFORM=${CMAKE_GENERATOR_PLATFORM})`
build/msvc: Add libiconv to bundled dependencies 2018-06-06 18:39:17 -07:00			`else()`
			`message(FATAL_ERROR "Trying to build libiconv in an unsupported system ${CMAKE_SYSTEM_NAME}/${CMAKE_C_COMPILER_ID}")`
			`endif()`

			`list(APPEND THIRD_PARTY_DEPS libiconv)`