I have a project for which I generate a visual studio solution using cmake. That project links against a library built by a specific compiler version, which I cannot change / update! Therefore I need to compile my project with the same compiler version.
There are ways to setup the minor toolset version using CMake, however none of those that I have found are working like Id want them to.
The problem is: I can generate my vs solution and have cmake select the correct toolset version. However when I build the project with Visual Studio the compiler version does not match the version selected by cmake. I presume this is due to the fact, that Visual Studio does not care about CMakes build "ideas" and does not easily allow a minor toolset selection.
The only solution I have found so far is described in this link: https://devblogs.microsoft.com/cppblog/side-by-side-minor-version-msvc-toolsets-in-visual-studio-2019/
In Short you can (manually) edit every *.vcxproj File and override the toolset version with an import like so
<Import Project="$(SolutionDir)\Microsoft.VCToolsVersion.14.20.props" />. I wish to do this via the CMakeLists.txt or an argument, when generating the solution. I have tried:
Specifying the exact toolset version via the "-T" argument like so: -T v142,version=14.28.16.9 />
Modifying a "vcvarsall.bat" to pass the correct toolset version by appending "-vcvars_ver=14.28". This makes Cmake select the correct compiler.
For boths methods VS does not care. The only way I found working is modifying the *.vcxproj by hand. Otherwise VS always picks the newest minor version of the selected toolset (in my case v142).
Related
I'd like our developers to use one version of Visual Studio for all of our projects (where possible) - to that end, I've asked them to use VS2019 for some projects that were originally created in VS2010 and then migrated to VS2013.
A runtime behavior change occurred when running one of these old webforms applications in VS2019. I'm not sure why it's different since the dlls being used are the same and the compiled IL is the same for the method in question, but at the moment I don't really care about "fixing" it since it would require making code changes and regression testing the entire application; a path I'd like to avoid for the moment.
What I'd like to do is make sure VS2019 builds with the indicated tools so that we retain the old behavior. The project file is referencing tools version 12 (VS2013 is not installed), but when Visual Studio builds I see the following in the MSBuild output:
Project file contains ToolsVersion="12.0". This toolset may be unknown or missing, in which case you may be able to resolve this by installing the appropriate version of MSBuild, or the build may have been forced to a particular ToolsVersion for policy reasons. Treating the project as if it had ToolsVersion="Current". For more information, please see http://go.microsoft.com/fwlink/?LinkId=293424.
I installed MSBuild Tools 2013, but that didn't correct the issue before or after a restart. I also tried with tools version 15 and got the same error (VS2017 is installed).
MSBuild from the VS2019 dev command prompt worked, but I had to copy the 14.0 webapplication targets to a new folder named "16.0". I'm not sure why there is a 14.0 folder but no 12.0 or 15.0 folder without doing more searching online.
Is this a fool's errand, or am I missing something simple?
MSBuild from the VS2019 dev command prompt worked, but I had to copy
the 14.0 webapplication targets to a new folder named "16.0". I'm not
sure why there is a 14.0 folder but no 12.0 or 15.0 folder without
doing more searching online.
Update 1
This is just a prompt warning to ensure that you'd better use the related MSBuild version to build the project. It is designed as a reminder message.
But in fact, MSBuild does add backward compatibility feature.
The message is just a warning rather than an error and will not break the build process. And if it breaks the build process, it can prove that backward compatibility is not supported.
You can test it: use VS2019 to build a VS2017 or VS2015 projects and I am sure that it can built them successfully.
==============================================
Each version of VS creates a project that is built for the corresponding MSBuild version.
For example, in the project created in VS2010, its ToolsVersion="4.0", so when you use MSBuild from VS2010(msbuild v4.0), it will built without that warning.
VS2013-->ToolsVersion=12.0 , VS2015-->ToolsVersion=14.0 , VS2017-->ToolsVersion=15.0, VS2019--> ToolsVersion=Current
So when you build the project, you should try the related msbuild version to build them.
Although MSBuild supports backwards compatibility, the problem is always in the form of a warning, which has been troubling us during the project migration.
Solution
To solve it, you should use the related MSBuild to build the project with the corresponding ToolsVersion.
If you want to build them in VS2017, you should change ToolsVersion to 15.0 in every project's xxx.xxproj file.
If you want to build them in VS2019, you should change ToolsVersion to Current in every project's xxx.xxproj file.
More info, you can refer to my answer in this similar issue.
I have installed both tesseract:x64-windows and tesseract:x64-windows-static via vcpkg. In my Visual Studio project, I can #include <tesseract/baseapi.h> and it will automagically compile but I have no idea whether the static or dynamic version of the library is being linked and I also have no idea how to switch between them. What setting lets me see / change that?
For VS integration you could try out PR https://github.com/microsoft/vcpkg/pull/4361 or just set the MSBuild property VcpkgTriplet according to:
https://github.com/microsoft/vcpkg/blob/master/docs/users/buildsystems/msbuild-integration.md
I use Clang 6.0.0 (from the latest build of the Windows installer) with Visual Studio 2017 to build my project, and everything works fine except for one thing, it rebuilds every file every single time. Not only that, it even recompiles everything when no code changed at all and I merely use "Start Debugging" or "Start Without Debugging"! The .obj files are still there, but it doesn't seem to be reusing them, which of course is prohibitively slow!
This happens only when using Clang 6 with "LLVM-vs2014" set in my project, when I switch "Visual Studio 2017 (v141)" or "Visual Studio 2017 - Clang with Microsoft CodeGen (v141_clang_c2)" I don't have that problem, it only compiles what changed.
What could possibly cause this behaviour?
Edit: Maybe that's what the website means by "A 64-bit version is also available, but it doesn't integrate as well with Visual Studio."
You can use fafnir.
https://github.com/kazatsuyu/fafnir
Visual Studio manages build dependencies using .tlog file, but it appears to generate wrong dependencies for recent clang. To fix it, fafnir uses API hooking to SetFileInformationByHandle through DLL injection.
Usage
Download the latest version from the release page on GitHub
Unzip it
Run install.bat
Specify the path of the directory of LLVM/clang
Specify new_toolset_name (in the form of v[0-9]+_clang_.*)
References
(Written in Japanese) Visual Studioでも最新のClangを使えるようにしたらキャッシュされていなかった
(Written in Japanese) Visual Studioでも最新のClangが使いたい！
Following the instructions here,
I've installed prerequisites, downloaded the source for version 3.9 and had CMake generate LLVM.sln. Building the full solution takes some times, but seems to do what it's supposed to do.
When looking at get_library in bindings/python/llvm/common.py, the Python binding makes use of a file named "LLVM-<current version>.dll" but I can't find any "LLVM-3.9.dll" in the generated files.
How do I build LLVM-3.9.dll from source with Visual Studio?
You can check out my repository which is based on CRoger instructions and simply build the project LLVM.vcxproj in Visual Studio.
I want to use the compiler options described here:
http://randomascii.wordpress.com/2013/09/11/debugging-optimized-codenew-in-visual-studio-2012/
We have a base props sheet which gets included into all projects and would be the ideal place to set this option.
However, it seems that the compiler option changed name with Visual Studio 2013 with Update 3. Some developers in my department have not yet upgraded to this version, so I would like to dynamically select the correct name for this compiler option depending upon which version of visual studio is being used to build.
How can I do that?
I've seen there is a VisualStudioVersion property as described here: http://blogs.msdn.com/b/webdev/archive/2012/08/22/visual-studio-project-compatability-and-visualstudioversion.aspx
and here: Detect Visual Studio version from within MSBuild project
However, it seems that the value of that property changes depending upon the version of visual studio that was last used to edit the solution file, and it does not give the version of visual studio currently being used to build. (At least, that's how I read it, please correct me if that's wrong).
Hmm, also, I think it only gives the major visual studio version. I need to know which update version is being used too.