Add a way to customize Visual Studio sln name
I noticed that recent versions of CMake are now requiring a "literal, direct" call to project()
in the top-level CMakeLists.txt, issuing a warning if the call is not detected. The intent seems to avoid the project()
call to be issued only inside an include
directive, which seems a very reasonable requirement. The problem is that how it is now the check is very rough, also preventing any useful wrapping of project()
calls inside a macro or a function. I provide an example of a my_project()
function that wraps the call to project()
adding useful suffixes to project name:
macro(my_project projectName)
if (MSVC)
# On Visual studio add informative suffix to project name
set(PROJECT_SUFFIX "-${ARCH}")
if (NOT "${CMAKE_BUILD_TYPE}" STREQUAL "")
set(PROJECT_SUFFIX "${PROJECT_SUFFIX}-${CMAKE_BUILD_TYPE}")
endif()
endif()
project(${projectName}${PROJECT_SUFFIX})
endmacro()
In the top-level CMakeLists, I call my_project(Test)
, which want to be an indirect, but intended, call to project()
. In Windows this allow the Visual Studio solution to have an useful name like Test-${ARCH}-${CMAKE_BUILD_TYPE}.sln
. After the upgrade of CMake I now have this big warning that makes me uncomfortable. My specific issue has some obvious workarounds that are less elegant, but it would be probably solved better if there would exist a supported way to customize the VS solution name without changing the project name, something that doesn't seems to exist.
Alternatively, it seems to me that requirement of having literal call to project()
in the top-level CMakeLists is too strict and I'm sure there are other legit reasons to wrap it in macros or functions as I'm doing. In fact, I see that you added these CMAKE_PROJECT_INCLUDE_BEFORE
and CMAKE_PROJECT_INCLUDE
variables, but they seems just workarounds you added because of too strict check in your interpreter: you could have performed a narrowed check of just the unsafe situation, which I think it was having an unintended first call to project()
issued in included files. Usually a well designed language interpreter has all the context information needed to detect such conditions. I don't understand why you chose to go this way adding before/after variables for external scripts (which are of course less comfortable to use than just wrapping project()
in a macro/function) but it seems to me like a code smell.
I attached an example CMake project with usage of the above my_project()
macro that issued no warning before 3.15.