For a C++ project, I need to use gRPC. everything went well with MSVC143 compiler, And I did.
but I'm using Clang compiler in Visual Studio 2022. So, it must build by Clang.
I tired to do this, but, I'm getting too many errors at the compile time.
Here, you can see them:
I did the whole instructions according to this tutorial. As I've said before. It works very well when I choose MSVC as compiler.
It's pretty weird. What should I do?
Future Information:
Visual Studio 2022(it's the latest version).
Clang version 13.0.1(it's the latest version as well).
CMake version 3.24.1(it's the latest version as well).
This article says These steps require. I did them as well.
Windows To prepare for cmake + Microsoft Visual C++ compiler build
Install Visual Studio 2015 or 2017 (Visual C++ compiler will be used).
Install Git. Install CMake. Install Active State Perl (choco install
activeperl) - required by boringssl Install Go (choco install golang)
required by boringssl Install yasm and add it to PATH (choco install yasm) - required by boringssl (Optional) Install Ninja (choco install
ninja)
Related
I just downloaded and configured vcpkg. But when I tried to install a package, I got this error message:
error: in triplet x64-windows: Unable to find a valid Visual Studio instance
Could not locate a complete Visual Studio instance
Does it mean it is necessary to install Visual Studio to make the vcpkg available?
Considering that all my work is doing on clion and vscode, if it's necessary, what's the minimum required components should I install?
Or maybe it's just my wrong somewhere?
No, you do not need to install Visual Studio to use vcpkg. By default, vcpkg tries to build packages with the MSVC compiler if you are on Windows. You could install just the Visual Studio Build Tools, which would give you MSVC without installing the entire IDE, if you wish.
What compiler are you currently using?
If you happen to be using MinGW, you should tell vcpkg to use that. See: https://vcpkg.io/en/docs/users/mingw.html.
Disclaimer: I work on the vcpkg tool.
I recently switched from using the Visual Studio 2015 IDE to the Visual Studio 2019 IDE. Around that same time I started using vcpkg for library installations. I've been using a pre-build version of an earlier version of boost, which I compiled myself. Thinking I ought to switch to a newer version of boost using vcpkg, I installed it with:
vcpkg.exe install boost --triplet x64-windows-static
Yet when I look inside C:\dev\vcpkg\installed\x64-windows-static\lib I see that vc140 - the Visual Studio 2015 toolset - is the version of boost built. Note that I am not using cmake. I am working purely in the IDE. How do I tell vcpkg I want the vc142 toolset, the version for Visual Studio 2019, built?
The answer is a modified version of the GitHub issues,
Edit file from your VCPKG path
vcpkg\triplets\x86-windows.cmake
To add line
set(VCPKG_PLATFORM_TOOLSET v142)
I tried to install vcpkg for VS code and in a PowerShell Window. I had this error:
Could not find MSBuild version with C ++ support. VS2015, VS2017 or VS2019 (with C ++) must be installed.
So I installed Visual studio and I have the same error. What should I do?
Run vcpkg integrate install to customize Visual Studio Code on Linux or macOS. This command sets the location of the vcpkg enum and enables IntelliSense for the source files.
Look at this web page: https://learn.microsoft.com/ru-ru/cpp/build/vcpkg?view=msvc-160#integrate-with-visual-studio-code-linuxmacos
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'm trying to compile, on Windows 10, a C++ project that is using C++14 features such as std::make_unique<> and things like that.
I'd like to be able to compile easily in command line, using CMake and make and then be able to run my program from any command line or just by clicking it's executable.
Compiling using Cygwin, even if it's indeed working (I used this tutorial), is not an option since the resulting executable won't be usable outside of the Cygwin environment due to missing DLLs.
I've read about MinGW-w64, but it seems like the latest available version for Windows corresponds to GCC 4.8.3.
Same goes for the MinGW installer mingw-get-setup.exe available here, wich only allows me to install the 4.8.1-4 version.
So I'd like to have a procedure on how to compile a C++14 project using CMake, and that will allow me to launch the executable in the default Windows environment.
Thanks.
Update : Chris Drew commented that I could use the latest Visual Studio version to build my project using the Visual C++ compiler instead of GCC. I detailed the workflow in my answer, but I'm still looking for a "GNU-style" way to compile it.
"GNU-style" : Use the link provided in Tive's comment to install a working GCC 5.1 environment and use the normal cmake . -G"Unix Makefiles" && make commands.
See this answer for more details on both solutions.
Using Visual Studio compiler
Following Chris Drew comment, here's what I did in order to compile using CMake to generate a Visual Studio 2015 solution and compile this solution in command line.
Note that this is not using the GNU toolchain as we won't be using gcc / make but the Visual C++ Compiler.
Creating and moving to a build subdirectory (it's recommended since it will generate a lot of files, instead of just a standard Makefile) :
mkdir build && cd build
Generating the Visual Studio 2015 solution :
cmake . -G"Visual Studio 14 2015"
This will generate several project files including YourProjectName.sln that we will use to build the project using the following command :
msbuild YourProjectName.sln
Note that msbuild was not in my PATH, so I had to provide the complete path to the executable wich was, in my case, C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe.
Using an updated MinGW installer
Tive provided a link to a bundled installer that will automatically install GCC 5.1 on your system, this way you can use the normal GNU toolchain by generating an Unix Makefile, and using the make command.
Note that you will need to edit your PATH manually as the installer is not doing it for you.