I used to program at Qt Creator in linux But now I am working on Windows and Visual Studio (I am forced to it). When I was programming in Qt Creator these features was so great and useful for me:
Opening several cmake project at the same time and easy switching between them.
There was no need to run cmake command in terminal before opening the project and Qt Creator was handling this matter itself. Therefore, if there was any error in CMakeLists.txt I could correct it from inside of Qt Creator
Now, In Windows you should run cmake command in cmd before you open the project in Visual Studio.
Are there any Extensions or Add-on's for Visual Studio to have the mentioned features of Qt Creator for opening a cmake project?
Do you have any other suggestion for working on a cmake project in Visual Studio?
For your first question, Visual studio provide you a complete solution and you can add and switch between projects easily inside a solution. (see differences between projects and solutions in this post)
But for your second question, I don't know any official extension to do that. But once you created a solution with Cmake, you can easily change the CmakeList in VS.
If you insist in doesn't running Cmake commands, you can write an extension for visual studio see this for more information.
No. QtCreator plays better with cmake than Visual Studio. With QtCreator you can open the CMakeLists.txt as a "project" and run the cmake config step directly. With Visual Studio, you must run the initial cmake config (with the generator option) first to generate the projects and solution. With QtCreator you can also open multiple projects (corresponding to multiple top-level CMakeLists.txt files) together. With Visual Studio, you can only open one solution at a time, and each top-level CMakeLists.txt corresponds to a solution.
While QtCreator works better with cmake than Visual Studio, cmake and Visual Studio are still an excellent combination (and as a whole my preferred working toolset)--just one for which you must run the inital cmake configure step before being able to open the solution. Note that it is just the initial cmake config step that is required. Once you have generated the solution and project files and are using the VS IDE, subsequent changes to CMakeLists.txt files or any input files to the configure_file command will cause cmake to reconfigure before VS builds the solution.
Also Visual Studio 2013 works better than 2010 because when you do trigger a cmake reconfigure it will ask you if you want to reload all the projects. VS 2010 will prompt you to reload each one, which is a pain when you have a lot of projects. (I typically have 20-100 projects in a medium to large codebase.) And sometimes VS 2010 will crash with cmake reconfigures. (Nothing is lost--it is just a pain to have the IDE crash and have to re-open it.)
As for other suggestions:
my comment above about automatic reconfigures, is based on not setting CMAKE_SUPPRESS_REGENERATION to ON as suggested in a comment above by drescherjm. (Based on your workflow, this may be a fine way to proceed, it just conflicts with the way I have used cmake/VS and will prevent reconfigures as I described.)
For building you do not have to use the vcvarsall.bat script as described by DevSolar because that is all sorted out by cmake with the -G argument. For a 64-bit build with VS 2013, I use -G "Visual Studio 12 2013 Win64". (Note VS 2010 is vc10, VS 2012 is vc11, and VS 2013 is vc12.) It is still, however, helpful to have a correct runtime environment, which I get using
call "%VS120COMNTOOLS%....\VC\vcvarsall.bat" amd64
You can get a command line build by cd'ing to the build directory (the one containing the generated solution file) and executing
cmake --build . --config Release
You can also specify which project to build by adding --target MyProject
Now (2015), in Windows you should run cmake command in cmd before you open the project in Visual Studio.
Not anymore, with recent version of Visual Studio 19 (2020): See "Build systems and projects"
Open a folder that contains a CMakeLists.txt file.
CMake support is integrated into Visual Studio. You can use the IDE to edit, test and debug without modifying the CMake files in any way. This enables you to work in the same CMake project as others who might be using different editors.
CMake is the recommended approach for cross-platform development. For more information, see CMake projects.
No need to generate any files first.
That is why a project like Git, for instance, will ignore said generated files: they are not needed anymore to open a CMake project:
With Git 2.29 (Q4 2020), using the CMake support added some time ago for real with Visual Studio build revealed there were lot of usability improvements possible, which have been carried out.
See commit 0ad621f (30 Sep 2020) by Junio C Hamano (gitster).
See commit f2f1250, commit b490283, commit 2d9eb4e, commit 8c35e82, commit f1bd737, commit 8f45138 (30 Sep 2020), commit e18ae4e, commit 72b6eeb (28 Sep 2020), and commit 3eccc7b (25 Sep 2020) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit 8250ab0, 05 Oct 2020)
cmake: ignore files generated by CMake as run in Visual Studio
Helped-by: Đoàn Trần Công Danh
Signed-off-by: Johannes Schindelin
As of recent Visual Studio versions, CMake support is built-in: https://learn.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=vs-2019
All that needs to be done is to open the worktree as a folder, and Visual Studio will find the CMakeLists.txt file and automatically generate the project files.
Let's ignore the entirety of those generated files.
That has practical consequence on a project on-boarding.
If we take the example of a project like Git, again:
cmake (Windows): initialize vcpkg/build dependencies automatically
Signed-off-by: Johannes Schindelin
The idea of having CMake support in Git's source tree is to enable contributors on Windows to start contributing with little effort. To that end, we just added some sensible defaults that will let users open the worktree in Visual Studio and start building.
This expects the dependencies (such as zlib) to be available already, though. If they are not available, we expect the user to run compat/vcbuild/vcpkg_install.bat.
Rather than requiring this step to be manual, detect the situation and run it as part of the CMake configuration step.
Note that this obviously only applies to the scenario when we want to compile in Visual Studio (i.e. with MS Visual C), not with GCC. Therefore, we guard this new code block behind the MSVC conditional.
This concludes our journey to make it as effortless as possible to start developing Git in Visual Studio: all the developer needs to do is to clone Git's repository, open the worktree via File>Open>Folder... and wait for CMake to finish configuring.
Related
It seems like this should be easy and I've spent hours trying to find this answer online but haven't had any luck.
I can open the CLion folder path in Visual Studio, but that option doesn't give me the usual options to build and start the project. To do that, I need to open CLion as a Project/Solution, but I can't seem to do this.
My professor requires that my C++ code be executable in Visual Studio, but I prefer CLion. So I've done all my work in CLion and want to test that it runs in Visual Studio. How can I import my CLion project?
Thanks!
The link provided describes Visual Studio's CMake integration, which (similar to CLion) will install a version of CMake that Visual Studio will use. These instructions are pretty thorough and should provide everything needed to get your CMake project working in Visual Studio.
Now, you probably have two versions of CMake installed on your machine, one that came with CLion and one that came with Visual Studio. I would recommend installing the latest version of CMake on your machine separately, and configuring both Visual Studio and CLion to use that version instead. However, this is probably getting outside the scope of your immediate problem.
As you follow the Microsoft's instructions for "CMake projects in Visual Studio", you mentioned receiving the error:
1> [CMake] CMake Error at C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.17/Modules/CMakeDetermineSystem.cmake:173 (file):
1> [CMake] file failed to open for writing (No such file or directory):
This looks like a permissions issue, specifically while running CMake within Visual Studio, so be sure you have read/write access to all the files in your project, and the CMake packages in your Visual Studio installation. Hopefully, this doesn't require you re-install Visual Studio in another location on your machine, or run Visual Studio with elevated privileges, but perhaps that is necessary.
If you decide to install CMake separately, the instructions would be the following:
Install the latest CMake on your machine (somewhere you have adequate permissions), and ensure it is available in your Path environment variable. You can verify this by running cmake -version from the command line to see it is the version you just installed.
Using Windows command prompt, navigate to your CMake project directory (containing the top-level CMakeLists.txt file), and run the following:
mkdir build
cd build
cmake -G "Visual Studio 16 2019" -A x64 ..
You may run -A Win32 with the cmake command instead if your project is a 32-bit build.
Open the .sln Visual Studio Solution file that was generated in the build directory. Once, the Solution is loaded in Visual Studio, you can build the project (CTRL + SHIFT + B).
I wiped out an old Windows 10 and replaced it with a new Windows 10 by ISO image.
Before wiping out, I copied the folder of Microsoft Visual Studio 2017 Community Edition on old Windows to an external hard disk:
xcopy /E "C:\Program Files (x86)\Microsoft Visual Studio" D:\
Now after reinstalling Windows 10, I copied the VS 2017 folder from external the hard disk to the C:\Program Files (x86)\ folder of new operating system.
I did so to avoid having to download VS 2017 again on new OS.
The problem is other software, like Qt Creator, cannot auto-detect the VS C/C++ compilers. I guess that's because the VS 2017 isn't added to path.
The questions are:
What path should I add to system path in order to VS 2017 to be auto-detected by other software like Qt Creator?
Is there any script which I can run to automatically integrate the VS 2017 to the rest of the operating system.
To answer the questions in your issue:
Copying the content of C:\Program Files (x86)\Microsoft Visual Studio folder is not a recommended way to install VS.
(The complete installation will not only set the Environment variables but also set the related registry keys and values. A simple copy may break this process)
So we always suggest that users install the VS by vs-installer or offline installation package. (Same like what Zlatomir suggests.)
To your actual requirements:
It seems you're just trying to use VC++ compiler in QT Creator instead of developing QT projects in Visual Studio. So build tools for VS package is enough for you.
See this related issue, if we download Build Tools for VS package with corresponding C++ workload, then we can get the compiler the QT needs. There's no need to install the VS IDE for this situation.
And if we need C++ compiler from VS2017, download the Build Tools for VS2017, if we need C++ compiler from VS2015, download the Build Tools for VS2015 Update3. Link of old version about VS Tools see here.
Update:
From the the link older downloads we can see:
Choose the download button according to which version we need. We can find both VS2017 build tools package and VS2015's there.
Usually programs on Windows don't work after you just copy the installation folder.
So right now there is little you can do to fix it, even if you partially fix, you have no way to know if something else will be broken in the future.
So the recommended solution is to download the installer again and create an offline installer for the next time this happens, you can do that by running the online installer with the following parameters: vs_community.exe --layout c:\vslayout --lang en-US (replace vs_community.exe with the actual name of the online installer file, or rename it), for more options, that might require a smaller download (example if you only need native and don't need .net) check the documentation here for the full set of options you have.
I need to build a dependency that uses SCons, and I need to build it with VC++2017, because another dependency I have cannot be built with VC++2019.
SCons successfully detects VC++2019 (v14.2), but not VC++2017 (v14.1):
c:\Python27\Scripts\scons [...] --msvc-version=14.1 [...]
scons: Reading SConscript files ...
scons version: 3.1.1
python version: 2 7 13 'final' 0
scons: warning: VC version 14.1 not installed. C/C++ compilers are most likely not set correctly.
Installed versions are: ['14.2', '14.0', '11.0']
[...]
C++ compiler $CC does not work
I have installed Visual Studio 2019 Enterprise as well as Visual Studio 2019 Build Tools, and for both, I have installed the platform tools / compiler for v14.1 and x86/x64. Compiling with the VC++2017 platform tools works fine in Visual Studio 2019 as well as using MSBuild, so the problem seems to be with SCons only.
How does SCons detect VC++2017 and VC++2019 and where should I start looking for the problem?
(There are old threads about this, but most of them are about people wondering why the "classic" detection/config methods using registry and vcvars.bat no longer work, so these are not helpful)
For current scons, it will believe what it gets back from vswhere.exe for the versions where that tool is considered definitive - 2017 and 2019. You can try seeing what that gives you.
vswhere -products * -property installationPath
That information is used to help locate the desired vars.bat file which imports the seetings needed.
I have found a perfect and simple solution:
Open file MSCommon/vc.py, find line: vc_pdir = os.path.join(vsdir[0], 'VC')
Change [0] to [1]
Re-build, the python will use vs2017
The reason is: if you install multi vs versions, the vsdir[0] is the highest one
Update: This is still (2021-09-16) an issue, and a simple workaround may be this answer - My answer also has a workaround, but it is more complicated and mostly for educational purposes on how recent versions of VC++ compilers can be detected and are (not properly) detected by SCons. You may also want to use my workaround if you are creating a build script for a build server or multiple development machines with varying setups.
The current version of SCons does not support selecting MSVC v14.1 (aka "Visual C++ 2017") if Visual Studio 2019 is installed, but Visual Studio 2017 is not. I confirmed this by looking at the code of SCons (see below).
An alternative approach is to use the --msvc-script option instead of --msvc-version.
In the MSVC installation folder, typically c:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\, you will find a file called vcvarsall.bat. If you run this without arguments, you will see that you can give it arguments for target platform and tools version, e.g.,
vcvarsall.bat x86 10.0.17763.0 -vcvars_ver=14.1
to compile for x86 (32-bit), Windows SDK version 10.0.17763.0 and tools version 14.1 (Visual C++ 2017).
Once you have found a command line for vcvarsall.bat that suits you, put it into a new BAT file that you create, say myvcconfig.bat (You have to use the complete path to vcvarsall.bat), then use the following command-line switch to SCons: --msvc-script=myvcconfig.bat.
*** Notes ***
Some parameters to SCons are redundant and will not work with --msvc-script, for example --32. SCons will tell you about them, so just remove them from the command-line.
The installation path of Visual Studio may be different from the one I provided above. You can find the installation path using Microsoft's own VSWhere tool. See also Locate Visual Studio
Visual Studio 2019 and Visual Studio Build Tools 2019 are separate installations with separate build tools. You can detect and use the vcvarsall.bat files of either ones. For example, if you are setting up a toolchain for a build server, you may want to use Visual Studio Build Tools 2019. If you just want to build one library one time (as in my case), just use the Visual Studio that is installed on your dev machine.
In case you are interested in how SCons detects MSVC and why it doesn't work, you can look at the source code in SCons/Tool/MSCommon/vc.py. You can clone the SCons GIT repository.
UPDATE: The following comment in vc.py (as of 2021-09-16) shows why this is still an issue in SCons and why this workaround is needed if you have both VC2017 and VC2019 compilers installed:
# make sure the cl.exe exists meaning the tool is installed
if ver_num > 14:
# 2017 and newer allowed multiple versions of the VC toolset to be
# installed at the same time. This changes the layout.
# Just get the default tool version for now
#TODO: support setting a specific minor VC version
Direct link (valid at time of writing)
I am trying to compile GDCM 2.8.4 for Windows. Can anybody describe how to compile it with Visual Studio 2013 Professional? The GDCM wiki is out of date. Thanks a lot.
First of all, you will have to install CMake. Then
Start CMake GUI.
I guess you already have the gdcm-2.8.4 directory (in a directory X:\XXXXX\ ) containing
Applications
Source
Testing
Utilities
and other subdirs. So set the in the CMake GUI "source dir" to X:\XXXXX\gdcm-2.8.4 . (NOT to its Source subdir!).
Then you create a new directory, where CMake will create the VS projects, let's call it X:\XXXXXX\GDCM-VSProjects. In the CMake GUI set "Where to build the binaries" to X:\XXXXXX\GDCM-VSProjects.
Then, in the CMake GUI press "Configure".
After configuring CMake offers you some options; choose at least GDCM_BUILD_APPLICATIONS, GDCM_BUILD_EXAMPLES, GDCM_BUILD_SHARED_LIBS. For documentation you will need doxygen, latex and possibly more.
Then, in the CMake GUI press "Generate". Now a lengthy calculation is performed and finally VS solution and VS subprojects are generated into your new X:\XXXXXX\GDCM-VSProjects subdirectory.
Now you can open GDCM.sln in VisualStudio and BuildAll in 64 bit Release mode.
After the build, you will find libs, dlls and exes in the bin/Release subdirectory of your X:\XXXXXX\GDCM-VSProjects.
Thats it.
Is there anyone who succeed to include libjpeg in some compiler? I tried everything: Dev C++, VS10, CodeBlocks, copy the headers and the lib by hand, add with the linker but nothing. Right now I am really confisued as there is not an official guide on how to compile it in any compiler. I would be really happy if someone could provide a tutorial on how the library can be compiled in any compiler.
Thank you in advance.
To compile libjpeg 9 in Visual Studio 2012, here are the steps (after unzipping the archive file):
Download the file WIN32.MAK (for example, from http://www.bvbcode.com/code/f2kivdrh-395674-down), and place a copy in the root source code directory (possibly C:\jpeg-9, but it depends where you unzipped it). I will refer to this directory as %jpegsrc% from now on. Having this file is important; otherwise step 3 will produce an error.
In the Visual Studio command prompt, open to %jpegsrc%:
cd %jpegsrc%
At the same command prompt, execute the following:
NMAKE /f makefile.vc setup-v10
This will create two Visual Studio 2010 solutions in %jpegsrc%: jpeg.sln and apps.sln.
Open each solution in Visual Studio 2012. Each one will prompt you to update all the projects to 2012 format. Click on “Update.” One time I did it, the prompt did not appear. In case that happens, right-click on the jpeg solution in the Solution Explorer, and choose “Update VC++ projects...,” which will produce the same prompt.
Save and build each solution as normal. (You have to build the jpeg.sln solution before apps.sln, since the latter depends on the former.)
Note: this process should work correctly in Visual Studio 2010, without the updating, but I have not tested it.
Update: This method still works in Visual Studio 2015 for libjpeg-9a.
Here is how I've built libjpeg using MinGW on Windows :
1. Get MinGW with MSYS
I've got a copy from http://sourceforge.net/projects/mingw/.
Quoting from www.mingw.org :
MSYS is a collection of GNU utilities such as bash, make, gawk and grep to allow building of applications and programs which depend on traditionally UNIX tools to be present.
We will need it to run the configure script that comes with libjpeg sources.
2. Get libjpeg sources
From http://www.ijg.org/, take the Unix format package (the Windows one won't work with this procedure). I took the jpeg_8d version.
3. Prepare a building directory
I've made a temporary directory named tmp in D:\, but you could choose whatever suits your needs. The thing that matters is the name of paths in MSYS. As it brings some * Unixity * to Windows, paths cannot be used in their original form.
In a nutshell:
C:\path\to\file becomes /c/path/to/file in MSYS land, an so
D:\tmp becomes /d/tmp.
Decompress the libjpeg sources in D:\tmp, so you have a jpeg-8d directory in there.
Create a jpeg-build directory inside D:\tmp, it will hold the built library.
Now everything is ready for the build.
4. ./configure, make, make install
That is the mantra of building in Unix land. An option should be added to redirect the install process to D:\tmp\jpeg-build.
Run the following commands in an MSYS shell (also named MinGW shell in Windows start menu):
cd /d/tmp/jpeg-8d
./configure --prefix=/d/tmp/jpeg-build
make
make install
As an additional step, you can run make test for safety.
These commands will build both static and shared versions of libjpeg.
5. Take the goods, delete the temporaries
If everything runs fine, you can delete the D:\tmp\jpeg-8d directory, but keep the jpeg-build one. It contains:
an include directory, containing libjpeg headers. You can move them to your compiler's headers directory.
a lib directory, with .a file to pass to the linker. You can move them to your compiler's library directory.
a bin directory, holding the libjpeg shared library libjpeg-8.dll and jpeg tools.
a share directory, containing man pages for the jpeg tools.
You can now build your program and link it against libjpeg by indicating the right include and library paths.
You can find many details about the libjpeg building and installation process in install.txt inside the source package.
I hope this will be useful.
It is really simple to build jpeg.lib with VS10.
First, download the libjpeg source code in zip format. At the time I'm writing this you can find it here.
Then extract the contents of the zip file to your disk.
Then open a VS2010 command prompt shell (or call vcvarsall.bat on any command prompt window), cd to the jpeg source directory (jpeg-8d in the download referenced above) and type the following:
nmake -f makefile.win setup-v10
This will generate two VS2010 solutions, and a bunch of project files. The solutions are:
jpeg.sln, which builds jpeg.lib
apps.sln, which builds the sample applications.
Good luck!
If you don't happen to have Visual Studio 2010 installed, here is what works on Visual Studio 2017:
Basic / Common steps:
Download the latest version of libjpeg from: http://www.ijg.org/ (zip version) and extract it to a folder
Open the "Developer Command Prompt for VS2017"
Change directory (cd) to where you extracted the library source
VS 2017 Approach:
Include the Windows SDK v7.1A directory (required for Win32.Mak by nmake later on) by running: set INCLUDE=%INCLUDE%;c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include
Run nmake /f makefile.win setup-v15 (note the v15 for VS2017 here)
From here on follow what #AthanasiusOfAlex explained to upgrade the Visual Studio 2010 solution to the Visual Studio version you are running. If you want the Debug configuration, follow what #SteveEng explained.
Errors you might stumble across:
If nmake fails and tells you it doesn't know how to make
jconfig.h, manually rename the file jconfig.vc to jconfig.h
If nmake fails and tells you Win32.Mak cannot be found, manually copy it from the SDK dir mentioned in step #4 to the libjpeg source directory. If you don't happen to have that SDK version installed, download the file from a trustworthy resource.
If nmake fails and tells you it doesn't know how to make setup-v15, trial and error your way through starting with setup-v10, setup-v11, etc... These are VS versions and one of them should work as long as you have any VS version later than VS 2008 installed.
Hope this helps people going through similar pain with this.
If you want debug mode as well in MSVC. Follow AthanasiusOfAlex's method, build the release, then:
Right-click on the project and select properties at the very
bottom
Click on configuration manager and on the active solution
configuration drop-down select -new-
Set the name to debug and on
the drop-down select copy configuration settings from release and
click OK
Close the dialog, go to general settings and under Target
Name add a d to the end so it looks like this: $(ProjectName)d
On Whole Program Optimization drop-down select: No Whole Program Optimization
Then click on the C/C++ under configuration properties on the left and on the Debug Information Format drop-down select C7 compatible (/Z7)
Under optimization select disabled and select NO for both Enable Fiber-Safe Optimizations and Whole Program Optimizations
Under preprocessor, preprocessor definitions, click on edit and use the following:
WIN32
_DEBUG
DEBUG
_LIB
_CRT_SECURE_NO_WARNINGS
Under code generation, under runtime library select Multi-threaded Debug DLL (/MDd)
Build and you're done!
This is for VS2019 with version number 16.0
Consider the Visual Studio Version name correctly like this for creating the .sln file.
Product name Code name Version number
Visual Studio 2019 Dev16 16.0
Visual Studio 2017 Dev15 15.0
Visual Studio 2015 Dev14 14.0
Visual Studio 2013 Dev12 12.0