I've never used CMake on Windows, or with MSVC, before; so this is a newbie question.
I've installed CMake and some minimal freely-downloadable "Microsoft Visual C++ build tools 2015" (from here) on a Windows 10 machine. I have my CMake-based project (which builds fine on Linux) checked out, and I'm ready to go.
So, in a shell window, I do:
PS C:\Users\joeuser\the_project> mkdir build
... etc. etc. ...
PS C:\Users\joeuser\the_project> cd build
PS C:\Users\joeuser\the_project\build> cmake ../
-- Building for: Visual Studio 14 2015
-- Selecting Windows SDK version to target Windows 10.0.15063.
-- lots of checks here
-- etc. etc.
and that's done. So far so good. But - what now? On a Unix'ish system, I would execute make, and perhaps make install; and maybe make clean later on. My questions are:
Do the MSVC tools I'm using have an equivalent of make? I've head about nmake and msys but I'm not sure those are relevant here.
What do I do now in order to build, install or clean the build directory?
Is it better/easier/more common practice to use a different CMake generator in my scenario?
Making my previous comments an answer:
You would then call the underlying build tool directly via CMake:
cmake --build . --target ALL_BUILD --config Debug -- /nologo /verbosity:minimal
This gives you an almost quiet build process as you are used to from make.
Why the hell do I have to provide so much arguments to CMake?
Because CMake is a build system generator and directs those arguments to the underlying build tool (make, MSBuild, nmake, ...). The underlying build tool may have different naming conventions for targets etc., e.g. make users provide almost always the targets all, clean, and install. But the Visual Studio solution generated by CMake uses by default ALL_BUILD, INSTALL, RUN_TESTS. There is no CLEAN target. Using MSBuild,
To install your solution you would select --target INSTALL.
For running tests, you would select --target RUN_TESTS.
For cleaning you have to use --target ALL_BUILD --config Debug -- /nologo /verbosity:minimal /t:Clean because the Visual Studio solution does not contain a clean target but MSBuild provides one.
Further important arguments of MSBuild are:
/maxcpucount:<numberOfCpus> (to limit the number of CPUs the build process is using) and
"/l:FileLogger,Microsoft.Build.Engine;logfile=<YOUR_LOGFILE_NAME>" to save MSBuild output to file.
Related
When building tests on the Windows platform with Visual Studio from a CMake project, CTest is unable to locate the executables for it. The tests are located under a subfolder tests/, but the generated project files for Visual Studio appear to put all executables under bin/ in the build tree. Here is a snippet of the CMakeLists.txt for the tests folder:
project(tests)
enable_testing()
...
add_executable(basicTest basictest.cpp)
target_link_libraries(basicTest gtest_main)
add_test(basicTest basicTest)
When building this on Linux and Mac OS platforms, there is no issue, CTest can find and execute all the tests. For the command cmake -B build -S ., the tests can be found as expected under build/tests/basicTest. However, when using the Visual Studio Generator that comes with CMake on Windows, it outputs all binaries under paths with build/bin/$(ConfigurationName)/basicTest.exe. When running ctest -V, it reports that it tries the following paths:
build/tests/basicTest
build/tests/basicTest.exe
build/tests/Release/basicTest
build/tests/Release/basicTest.exe
build/tests/Debug/basicTest
build/tests/Debug/basicTest.exe
But never paths under build/bin/. If I copy the folder build/bin/Release/ into build/tests/ then CTest reports all tests were successful. What's the correct fix for this to make CTest operate correctly across all platforms?
Do I need to add something to the path used by the add_test() CMake command? Do I need to add a property to the targets to place them correctly, or a property to the tests to tell them where their executable is?
Bonus: This should probably be it's own question, but is there a straight-forward way to get vtest.console.exe to also run these tests? I can already run all the tests from the Visual Studio "Run All Tests" menu option.
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 am following this quick tutorial and I am not sure how to do the project setup part for my pre-existing VS 2017 project that uses the LunarG Vulkan SDK which includes the glslang and SPIRV folders. I tried using the table found here to convert the cmake commands in the tutorial; I was able to include the glslang directory but I cannot figure out what I should be adding to properties->linker->input->additional dependencies for linking with glslang and SPIRV. Do I have to somehow compile these first then link to them? In which case how do I do that?
Do I have to somehow compile these first then link to them? In which case how do I do that?
Yes. If you want to use the glslang tools at runtime instead of at build time, you need to first build them. The VulkanSDK contains the glslang source code, but not binaries. Since the interface to glslang is C++, not C like Vulkan, producing a binary that would work for everyone is basically a non-starter.
The tutorial you link to includes this:
add_subdirectory(${LIB_DIRECTORY}/glslang)
Which basically means "include this other CMake based project in my own", which would in turn mean that it would have the same build settings as your own CMake based project. In order to bypass CMake you would need to construct a Visual Studio project for glslang from scratch.
My advice to you is to stop trying to fit the tutorial into your pre-existing Visual Studio project and just use CMake to generate your VS project so that you can follow the tutorial directly. It's extremely unlikely that whatever settings you have in your pre-existing VS project can't be replicated in a CMake based VS project very quickly.
Alternatively, you can learn just enough CMake to create a project for glslang and build it, at which point you'll be able to use the binaries it creates as your linker inputs, BUT you'll need to make sure that the project settings in glslang generated project are sufficiently close to your own, in particular the Runtime Library and the 32/64 bit-edness and make sure that you don't mix and match release and debug builds across the dependency.
Here is a simple recipe for building glslang, assuming you have CMake installed and the VulkanSDK correctly installed:
mkdir %VULKAN_SDK%\..\glslang
cd %VULKAN_SDK%\glslang
mkdir build
cd build
cmake .. -G "Visual Studio 15 Win64" -DCMAKE_INSTALL_PREFIX=%VULKAN_SDK%\..\glslang
cmake --build . --config Release
cmake --build . --config Debug
cmake --build . --config Release --target INSTALL
cmake --build . --config Debug --target INSTALL
I have Visual C++ Build Tools 2015 | Standalone compiler, libraries and scripts installed on a low-end netbook. It's necessary, because the machine has a small eMMC soldered to the board with no real space available.
nmake is installed at %PROGRAM FILES%\Microsoft Visual Studio 14.0\VC\bin. However, CMake cannot find it when attempting to generate the Makefile. I'd like to use a -D to tell CMake what the makefile program is, but I am having trouble locating the list of -D defines for CMake.
For completeness, I'm trying to avoid other Microsoft tools. I have LLVM build tools at C:\LLVM\bin, so I'm setting CMAKE_C_COMPILER and CMAKE_CXX_COMPILER. But I needed nmake, because I can't find a stand-alone Make program for Windows already built.
What is the -D define to specify nmake for CMake?
The variable you are looking for is CMAKE_MAKE_PROGRAM.
If you try to set this variable plus CMAKE_C_COMPILER, CMAKE_LINKER_EXE, etc., this will still fail, because cl.exe and link.exe need some environment variables to be set. Those can be set by using a "Visual Studio * Command Prompt" (this uses vcvars.bat from the Visual Studio install directory).
To use Clang you can install a Clang toolset from http://llvm.org/builds/. Then you can specify CMAKE_GENERATOR_TOOLSET in a toolchain file.
Let me know how this works out for you.
CMAKE_MAKE_PROGRAM. See the documentation:
At this time (September 2015) there is no official Qt build for Visual Studio 2015. How to build it manually?
It can be built manually quite easily. The example below is for Qt 4.8.6.
Download Qt 4.8.6 sources:
http://download.qt.io/archive/qt/4.8/4.8.6/qt-everywhere-opensource-src-4.8.6.zip
and unpack. Let the Qt prefix be c:\Qt-2015\4.8.6\msvc2015. Copy sources inside the downloaded source dir to {prefix dir}.
Apply the patch 02-fix_build_with_msvc2015-45e8f4ee.diff
https://drive.google.com/file/d/0Bz6Oefew6XZnOU9ac0hIeG41UVE/view?usp=sharing
see post: https://forum.qt.io/topic/56453/compiling-qt4-head-with-msvc-2015-cstdint-errors/5
to get rid of compilation errors
(I applied all changes by hand, it's not so long).
Make new win32-msvc2015 spec in mkspecs directory:
create win32-msvc2015 directory, copy the contents of win32-msvc2013 dir,
edit qmake.conf: set _MSC_VER to 1900 and update all text from 2013 to 2015 where appropriate:
Edit makefile.win32 file in {prefix dir}/qmake/ directory:
find all win32-msvc2013 occurences and add win32-msvc2015 similarly:
Now from the Visual Studio 2015 command prompt
run (these are the example commands, additional commands may be different depending on the build needs):
configure -make nmake -platform win32-msvc2015 -prefix c:\Qt-2015\4.8.6\msvc2015 -opensource -confirm-license -opengl desktop -nomake examples -nomake tests
Option -make nmake
is need because configure.exe searches max version vs 2013 of nmake by default, otherwise it uses make.
Then for single core build command
nmake
(or jom.exe -jN, where N <= number of CPU cores).
That's all. This example is without Webkit, examples and demos - for speed.
For me it takes ~1.5 hours to build on the single core.