The Visual Studio 2019 project, which was built via cmake displays
File Modification Detected
The project ABC has been modified outside the environment
Reload ... Ignore ...
message.
How can I prevent cmake from updating the VS config files, for the project or system wide?
In what section of the cmake build files this behavior is defined (so that I can rebuild the project without this feature)?
No, you cannot prevent this (afaik). Consider the scenario where you add a source file to a target in a CMakeLists.txt file. CMake needs to update the Visual Studio project files it generated which results in project file(s) being overwritten. CMake sets up the solution in a way to ensure such an update on a modification of the cmake files. Visual Studio reacts to the solution/project files being overwritten by displaying the dialog you mentioned.
In general you'll want to click "Reload" which should just update the projects according to the modification in the cmake sources. If for a command line build tool shows up though, you may want to select "Ignore" though, since sometimes the build output is deleted on a reload of projects/the solution and you'll probably want to check the error message.
If you're interested: Overriding the project files happens in the ZERO_CHECK target.
If the dialog is displayed on a build even if you did not modify the cmake files since the last build, you may want to check the console for a warning in the output of cmake though; this may indicate that there may be some issue in your cmake files...
Related
I have a multiplatform CMake project, and occasionally I have to build it manually for Windows. I generate a buildsystem like this:
cmake -DCMAKE_BUILD_TYPE=Release -G"Visual Studio 16 2019" -A x64 ../path/to/source
Then I open *sln file and press F7 to build. It runs for 40 minutes, and after that I understand that I didn't select proper configuration in the combobox. It's annoying! When command line option was -DCMAKE_BUILD_TYPE=Release, but combobox was set to Debug, build fails after spending a decent time.
Is it possible to generate an MSVS project with build configuration selected from command line?
Note that I'm aware of msbuild command and it's -p:Configuration=xxxxx flag. The question is about cases when for some reason you need to build from Visual Studio's GUI.
Changing the selected configuration for the GUI is not possible with CMake at this moment.
The main reason for this is that this information is stored in the .suo file generated by Visual Studio. CMake itself only generates the project and solution files, while the .suo file will be generated by Visual Studio itself.
Alternatively, use CMake's command line build option for this. After configuring your project and generating the VS .sln file from CMake as usual, simply run:
cmake --build <path_to_build_directory> --config Release
This works independently of the selected generator and is the most reliable way of building CMake projects.
I decided to give the built-in CMake support in VS2017 a try, and instead of figuring out why our multi-library, multi-executable project has problems with find_package in the hand-crafted CMakeLists.txt files that it has used for years, I decided to try a simple project first, the FooBar example from the CMake wiki: https://cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file
This project creates a shared library foo and an executable bar that links to this library, and is about as simple as they come. I unzipped the project, opened it with File->Open->Folder, the CMake configuration starts and succeeds. Fist thing I notice is that there's no more Build menu, no F7 shortcut to build my project, but instead, I have to select CMake->Build CMakeLists.txt :-( The Debug menu is similarly stunted, and quick debugging is why I use Visual Studio in the first place. This is already looking bad, but it gets worse:
The build fails with this output:
foo.vcxproj -> C:\Users\Enno\AppData\Local\CMakeBuild\639e9ecd-8891-eb38-b26b-ce84aa448eea\build\x86-Debug\foo\Debug\foo.dll
C:\Users\Enno\AppData\Local\CMakeBuild\639e9ecd-8891-eb38-b26b-ce84aa448eea\build\x86-Debug\bar\LINK : fatal error LNK1104: cannot open file '..\foo\Debug\foo.lib'
Thoughts:
The build directory is in %APPDATA%? That's going to be annoying.
There is indeed no .lib file in that location, just the .dll.
At this point I was becoming skeptical that this may not be a problem with VS2017, but maybe with the sample project itself, or with CMake. So I created a solution for VS2015 with cmake.exe -G "Visual Studio 14" ., which I opened in VS2015 and Voila! I got the same error message.
Is there a CMake genius on SO that can tell me what is wrong with this project?
Turns out: The example on the CMake wiki is not portable in the first place, so this has nothing to do with Visual Studio's built-in CMake support. It does not take into account that Windows needs export libraries for DLLs. Adding the correct __declspec(dllexport) incantations to foo.h resolves the error message.
I found all the information that I needed about shared libraries on Windows at this link:
http://gernotklingler.com/blog/creating-using-shared-libraries-different-compilers-different-operating-systems/
Is there any way in CMake how to call a command that changes the generated .vcxproj files?
I want to patch some things within the auto generated files.
The problem is !when! to call such a tool within the cmake generation process.
I am trying to compile a Library using CMAKE-gui 3.0.2 and Visual Studio express 2013.
Everything seems to be fine during the configuration/generation process in cmake-gui, as I am able to set the CMAKE_INSTALL_PREFIX variable to the path in which I want to have my library installed. And I got no errors during configuration and generation.
I then open the generated .sln file in which I can build the ALL_BUILD target, which runs smoothly with no errors and no targets skipped.
However, the INSTALL target is simply not present in the Solution Explorer, therefore I really do not have any idea on how to install the library.
Upon further inspection, I noticed that cmake did create a file called cmake_install.cmake, but I don't know what should I do with it.
CMake will only generate the INSTALL target when there is actually anything to install. It would seem you have no install() commands in your project.
Presence of the variable CMAKE_INSTALL_PREFIX does not imply anything - the variable is always present, and is used to control the installation destination when there is anything to install.
Likewise, the file cmake_install.cmake is always created; but if you inspect it, you'll find it's basically a no-op in your case (probably just some messages, setting CMake variables and possibly creating a manifest which is not used for anything).
I am using cmake to generate project files for a C++ project that needs to be compiled under Visual Studio 6 and 2010. The files are generated OK for both projects and I can build the projects without a problems.
However, the 2010 vxproj files contain relative paths to the cpp files and when I use Jenkins to build the files the log contains relative paths that Jenkins can not use to find the source files.
I see this:
..\..\source\moduleA\file1.cpp(74): warning C4800: 'BOOL' : forcing value to bool 'true' or 'false' (performance warning)
While it should have been either source/moduleA/file.cpp or D:\jenkins\jobs\workspace\source\moduleA\file.cpp for Jenkins to be able to find the file.
Of course, I can make a parser to parse the log file and remove the ..\...\ but I am hoping to find a more elegant solution.
In the end I found a compiler option that can fix this. You can add the /FC flag for Visual Studio 2010. Not sure if it works for VC6. To add it use this:
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /FC")