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
    CONFIGURE_COMMAND ${CMAKE_COMMAND} -E copy
      ${CMAKE_CURRENT_SOURCE_DIR}/cmake/LibiconvCMakeLists.txt
        ${DEPS_BUILD_DIR}/src/libiconv/CMakeLists.txt
      COMMAND ${CMAKE_COMMAND} ${DEPS_BUILD_DIR}/src/libiconv
        -DCMAKE_INSTALL_PREFIX=${DEPS_INSTALL_DIR}
        ${BUILD_TYPE_STRING}
        -DCMAKE_GENERATOR=${CMAKE_GENERATOR}
        -DCMAKE_GENERATOR_PLATFORM=${CMAKE_GENERATOR_PLATFORM}
    BUILD_COMMAND ${CMAKE_COMMAND} --build . --config $<CONFIG>
    INSTALL_COMMAND ${CMAKE_COMMAND} --build . --target install --config $<CONFIG>)
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`
			`CONFIGURE_COMMAND ${CMAKE_COMMAND} -E copy`
			`${CMAKE_CURRENT_SOURCE_DIR}/cmake/LibiconvCMakeLists.txt`
			`${DEPS_BUILD_DIR}/src/libiconv/CMakeLists.txt`
			`COMMAND ${CMAKE_COMMAND} ${DEPS_BUILD_DIR}/src/libiconv`
			`-DCMAKE_INSTALL_PREFIX=${DEPS_INSTALL_DIR}`
build: only use CMAKE_BUILD_TYPE for single-config generators CMAKE_BUILD_TYPE is ignored for multi-config generators and creates a warning that it's unused. 2022-08-05 15:20:10 -07:00			`${BUILD_TYPE_STRING}`
build/msvc: Add libiconv to bundled dependencies 2018-06-06 18:39:17 -07:00			`-DCMAKE_GENERATOR=${CMAKE_GENERATOR}`
ci: bump Windows image to windows-2019 The VS 2019 CMake generator no longer has different generator types for different architectures. Now, the architecture is specified via CMake's `-A` switch. However, this requires we also propagate `${CMAKE_GENERATOR_PLATFORM}` to the bundled deps, so they build for the same architecture as Nvim. 2021-10-23 18:38:58 -07:00			`-DCMAKE_GENERATOR_PLATFORM=${CMAKE_GENERATOR_PLATFORM}`
build: consistently set build type regardless of generator or platform #19760 Change the default build type to always be Debug, and allow only four predefined build types: Debug, Release, RelWithDebInfo and MinRelSize. Furthermore, flags meant for single-configuration generator (make, ninja) will not be used for multi-configuration generators (visual studio, Xcode), and flags meant for multi-configuration generators will not be used for single-configuration generators. This will allow Debug builds to be built with MSVC which requires that all dependencies are also built with the Debug build type to avoid runtime library mismatch. The correct way to specify build type (for example Release) for single-configuration generators (Make and Ninja) is to run cmake -B build -D CMAKE_BUILD_TYPE=Release cmake --build build while for multi-configuration generators (Visual Studio, Xcode and Ninja Multi-Config) is to run cmake -B build cmake --build build --config Release Passing CMAKE_BUILD_TYPE for multi-config generators will now not only not be used, but also generate a warning for the user. Co-authored-by: dundargoc <gocundar@gmail.com> 2022-09-06 07:52:39 -07:00			`BUILD_COMMAND ${CMAKE_COMMAND} --build . --config $<CONFIG>`
			`INSTALL_COMMAND ${CMAKE_COMMAND} --build . --target install --config $<CONFIG>)`
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)`