missing CMAKE_BUILD_TYPE when using Visual Studio to build

[sangshuduo]

Platform: Windows 11 Pro, Visual Studio 2022

cmake -S . -B _build_vs2022x64 -G "Visual Studio 17 2022" -A x64 -DCMAKE_GENERATOR_TOOLSET=host=x64
-- The C compiler identification is MSVC 19.36.32532.0
-- The CXX compiler identification is MSVC 19.36.32532.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.36.32532/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.36.32532/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- GEOS: Version 3.13.0dev
-- GEOS: C API Version 1.18.0
-- GEOS: JTS port 1.18.0
-- GEOS: Using default build type: Release
-- GEOS: Run-time output: C:/Users/sangs/source/repos/geos.sangshuduo/_build_vs2022x64/bin
-- GEOS: Archives output: C:/Users/sangs/source/repos/geos.sangshuduo/_build_vs2022x64/lib
CMake Error at CMakeLists.txt:189 (set_property):
set_property could not find CACHE variable CMAKE_BUILD_TYPE. Perhaps it
has not yet been created.

-- GEOS: Require C++14
-- GEOS: Developer mode ENABLED
-- Looking for pow in m
-- Looking for pow in m - not found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - not found
-- Found Threads: TRUE
-- GEOS: Build geosop ON
-- GEOS: install runtime path for util: $ORIGIN/../lib
-- GEOS: Build astyle OFF
-- Configuring incomplete, errors occurred!

[sangshuduo]

append "-DCMAKE_BUILD_TYPE=Release" to the cmake command line will solve the issue.
I think the INSTALL file should mention it as the default command

[pramsey]

The variable is definitely not missing.

https://github.com/libgeos/geos/blob/main/CMakeLists.txt#L115-L121

Seems odd that the attempt to set the cache values is failing. The error message says the cache "has not yet been created" I wonder if the use of set() is the problem and there's something special to be done for cache variables.

[hobu]

The variable is definitely not missing.

This is now a frowned upon practice given that its caching will interact poorly with an IDE that's doing multiple build types. I suspect that's what's going on here.

GEOS should consider removing this and let default CMake machinery for CMAKE_BUILD_TYPE drive what happens.

[dbaston]

Maybe guard it behind GENERATOR_IS_MULTI_CONFIG or something, but I don't think it's a good idea to remove it. The default CMake machinery gives us a build with no optimizations, and unfortunately this is what was packaged in several distribution channels until we added the offending lines.

[hobu]

Maybe guard it behind GENERATOR_IS_MULTI_CONFIG or something, but I don't think it's a good idea to remove it. The default CMake machinery gives us a build with no optimizations, and unfortunately this is what was packaged in several distribution channels until we added the offending lines.

Completely reasonable.

[pramsey]

Can you do that @dbaston, I'm not 100% clear on what to guard where, while still addressing the core problem in this issue and without altering behaviour somewhere else. hashtag-jenga-blocks

[dbaston]

I was thinking about this: dbaston@a28090c though I haven't tried reproducing the issue reported here to see if that change resolves it.

[sangshuduo]

Does not work on my side.

C:\Users\sangs\source\repos\geos.sangshuduo (main) >git diff
error: cannot spawn delta: No such file or directory
diff --git a/CMakeLists.txt b/CMakeLists.txt
index e0a09e56f..894d78d7f 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -114,8 +114,12 @@ endif()

 # Make sure we know our build type
 if(NOT CMAKE_BUILD_TYPE)
-  set(CMAKE_BUILD_TYPE ${DEFAULT_BUILD_TYPE})
-  message(STATUS "GEOS: Using default build type: ${CMAKE_BUILD_TYPE}")
+  get_property(_is_multi_config_generator GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
+  if (NOT _is_multi_config_generator)
+    set(CMAKE_BUILD_TYPE ${DEFAULT_BUILD_TYPE})
+    message(STATUS "GEOS: Using default build type: ${CMAKE_BUILD_TYPE}")
+  endif()
+  unset(_is_multi_config_generator)
 else()
   message(STATUS "GEOS: Build type: ${CMAKE_BUILD_TYPE}")
 endif()

C:\Users\sangs\source\repos\geos.sangshuduo (main) >cmake -S . -B _build_vs2022x64 -G "Visual Studio 17 2022" -A x64 -DCMAKE_GENERATOR_TOOLSET=host=x64
-- The C compiler identification is MSVC 19.36.32532.0
-- The CXX compiler identification is MSVC 19.36.32532.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.36.32532/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.36.32532/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- GEOS: Version 3.13.0dev
-- GEOS: C API Version 1.18.0
-- GEOS: JTS port 1.18.0
-- GEOS: Run-time output: C:/Users/sangs/source/repos/geos.sangshuduo/_build_vs2022x64/bin
-- GEOS: Archives output: C:/Users/sangs/source/repos/geos.sangshuduo/_build_vs2022x64/lib
CMake Error at CMakeLists.txt:193 (set_property):
  set_property could not find CACHE variable CMAKE_BUILD_TYPE.  Perhaps it
  has not yet been created.


-- GEOS: Require C++14
-- GEOS: Developer mode ENABLED
-- Looking for pow in m
-- Looking for pow in m - not found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found`

[here-abarany]

@dbaston the CMake error is on the following line:

set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS "Debug" "Release" "MinSizeRel" "RelWithDebInfo" "ASAN")

Since CMAKE_BUILD_TYPE isn't a cache variable, this call to set_property() fails. This line needs to be skipped if it's not a cache variable, which includes the set(CMAKE_BUILD_TYPE ${DEFAULT_BUILD_TYPE}) fallback.

The default CMake machinery gives us a build with no optimizations, and unfortunately this is what was packaged in several distribution channels until we added the offending lines.

I can't speak for all distributions, but I know that Arch Linux prefers to use the CMake default configuration and uses CXXFLAGS to configure the default options, including enabling optimizations. I believe this is to more directly set system-wide default options. While there may still be some distributions that don't enable optimizations, not setting CMAKE_BUILD_TYPE isn't a guarantee that optimizations aren't enabled through other means.

As a consumer of the GEOS library, this puts us in an extremely bad situation:

1. GEOS 3.11.2 and earlier build on Windows, but not with GCC 13.
2. GEOS 3.12.0 builds on GCC 13, but not on Windows.

In other words, we don't have one version that can build on all the platforms we use...

[pramsey]

Do you have a PR we can test?

[here-abarany]

I can see about pushing something up.

Another thing worth noting: on Windows, C++ libraries built in Release aren't compatible with other libraries or executables built in Debug, and vice-versa. This is because Debug builds will have extra debugging functionality enabled for the STL and can cause crashes if there's a mismatch between debugging being enabled or disabled. (the ABIs are incompatible) I mention this because with the current where CMAKE_BUILD_TYPE is forced to Release, attempts to build both Debug and Release builds to link to other projects may end up creating incompatible binaries for the Debug version.

[here-abarany]

@pramsey I created #945 to fix the issue. I incorporated the change from @dbaston to avoid setting CMAKE_BUILD_TYPE entirely for multi-configuration generators and checked that CMAKE_BUILD_TYPE is a cache variable before attempting to set the CACHE property on it. This runs on both Windows and Linux.