Warning after switching to use environment variables

[thomb]

Hi,
I've been trying to make the output of CMake for the build-system portable without requiring someone to run CMake again.
I have created ENVIRONMENT variables on Windows for DCMTK_CODE_DIRECTORY, DCMTK_BUILD_SYSTEM_DIRECTORY, and CMAKE_BINARY_DIRECTORY.
This seems to have worked with all the changes I made to *.cxproj and *.vcxproj.filters files.
However when I run the build for the DCMTK solution, I get these warnings with a successful build.

4:22:01:531 1>C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(237,5): warning MSB8065: Custom build for item "C:\moved\cloned-repo-root\build-system\CMakeFiles\4fca62c0aec886ec489afdf8d3e8780d\generate.stamp.rule" succeeded, but specified output "c:\moved\cloned-repo-root\build-system\config\cmakefiles\generate.stamp" has not been created. This may cause incremental build to work incorrectly.

I'd love to get rid of these warnings.
What files have I missed when moving to Windows environment variables?
Thank you.

[thomb]

Those warnings are coming from the build of ZERO_CHECK.vcxproj

[Michael Onken]

You can suppress generation of by using

Code: Select all

set(CMAKE_SUPPRESS_REGENERATION true)

if the cmake files don't change "in the background" after creating the VS project files (or you don't care), see the related CMake documentation.

[thomb]

I decided to disable the ZERO_CHECK in Visual Studio's Configuration Manager for the DCMTK solution.
That eliminated the warnings and all else seems to have built.
Will skipping ZERO_CHECK this way have the same effect as changing the CMakeList.txt file as you described?
Thanks.

[Marco Eichelberg]

To my knowlege, setting set(CMAKE_SUPPRESS_REGENERATION true) should suppress the generation of the ZERO_CHECK target, which might be preferrable over manually tinkering with the list of build targets in the solution file.

[thomb]

I think I've been fighting an uphill battle. Attempting to avoid using CMake on every development machine to generate the build-system is very problematic.
If I didn't have the requirement to avoid this, I would be done.

[Michael Onken]

Can you expect every developer to put the project into the same folder, e.g. c:\my_project\src for the source code and c:\my_project\build for the build? If so, I would think the project is "portable". The project (sln) might still need cmake in the background, but I think it's portable as well (e.g. put and use it from c:\my_project\cmake.

[thomb]

That's exactly what I did. Forced folks to always use the same location for the cloned repository so they will have correct paths.
I also did that with Visual Studio 2022 and CMake.

Thank you very much for your responses to this thread and in the others.