Visual Studio 2017中的编译器工具布局
寫在前面
- 在工作中，偶爾會用到VC編譯器。目前，最新版的VS已發布到了2017。其中，微軟對于VS的目錄結構進行了調整。
- 該文翻譯自微軟官方博文 Compiler Tools Layout in Visual Studio 2017。水平有限，僅供參考！后面也附錄了原文。
- 微軟官網也有個翻譯版本，但是是機器翻譯的，錯誤有點多！
- 部分注釋為譯者添加。
- 需要注意的是，這篇文章是早期針對VS 2017 Preview 4的。目前，正式版的VS 2017可能有變化。
??這篇文章由 Andrew Pardoe、Mark Levine 和 Iyyappa Murugandi 撰寫。
??感謝您的反饋意見！ 根據您的反饋，我們已對布局進行了一些更改。
??2016年12月8日更新查找VC安裝的位置：一些人問如何在開發人員的機器上找到Visual C的實例。現在，已經沒有可以供查詢的注冊表值。如果可以啟動VS命令提示符，則會發現％VCInstallDir％環境變量指向VC安裝的根目錄。如果您需要以編程方式查詢安裝，則需要查詢COM以查找Visual Studio和VC的實例。希思·斯圖爾特用很多語言的示例代碼寫了一篇關于這個主題的優秀博客文章。
??只要一加載第一個項目，你就會在Visual Studio 2017中看到許多針對C開發人員的改進。但有些產品中的變化并不是那么明顯。其中一個特殊的變化可能讓你感到驚訝：我們已經改變了MSVC 編譯器工具集在磁盤上的位置。
為什么我們要移動編譯器工具集
??VS2015中編譯工具在磁盤上的布局反映出了我們近幾年來得一些決定。在2002年，我們發布 Visual Studio .NET 時，我們發布了僅支持x86架構的編譯器。x64以及itanium架構在近期的關于Visual studio .Net的開發中才被提及。 編譯器在磁盤上的布局僅僅適用于只會使用x86編譯的情況。
注意：
??1. itanium架構目前英特爾好像已經放棄！
??當我們引入對Itanium和x64體系結構的支持時，我們在編譯器的合理位置添加了它：bin目錄中。由于在bin目錄中，已經存在一個x86編譯器，所以我們相應的添加了子目錄x86_ia64和x86_amd64。 這些子目錄的編譯器可以運行在x86平臺并生成64位平臺代碼。 還有amd64目錄下的編譯器，運行在x64平臺下，用來生成x64平臺的代碼。
??不過，事情遠不止于此。后續，我們又增加了針對ARM平臺的編譯器。接著，有添加了在X64平臺上運行的針對，x86和ARM平臺的編譯器。最終，形成了一個負責的樹形目錄結構。每當開發人員想要編寫與我們的編譯器有關的自動化時，他們都必須在其x86平臺的腳本中對編寫特殊情況。
編譯器工具集轉移到VS 2017后的位置
??首先，我們先討論編譯器工具集的主要部分。.它們分布在最上層目錄，例如：%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Enterprise\VC. (注意這個改變的目錄（也就是%VCINSTALLDIR%）之前在VS2015中的目錄是 %ProgramFiles(x86)%\Microsoft Visual Studio 14\VC.)
- Tool： 這個目錄就是一般認為的MSVC編譯器的工具集目錄。包含早期的bin，crt，include和lib這幾個目錄及這些目錄之中的一些二進制文件。這些二進制元文件包括cl.exe和link.exe，還有相應的頭文件以及VC++運行時需要的庫文件。
- Redist： 可再發行組件目錄。可由最終開發人員使用構建的應用程序重新分發的文件。CRT redist就位于此目錄下，其他運行時例如AMP、OpenMP也包含在里面。
- Auxiliary： 這個目錄包含了輔助編譯工作但不是必須的一些工具和腳本。比如配置開發者環境的vcvars*.bat腳本、CppCoreCheckers 、Unit Test libraries。
??請注意，目前VS2017預覽版5中的編譯器工具集布局就是個預覽版。 根據來自內部和外部開發人員的反饋和要求，我們最終可能會更改布局甚至頂級%VCINSTALLDIR%目錄。
注意：
??目錄如下圖：
Tool目錄
??讓我們進一步看一下Tools目錄——該目錄包含編譯器工具集。 和VS2015安裝目錄不同， 微軟Visual C++編譯器所在的目錄命名為MSVC。如果在安裝時你選擇了Clang with Microsoft codegen選項并安裝。 你將會看到MSVC目錄后面緊接著一個叫做clangC2的目錄， 它里面包含了Clang/C2的二進制文件.。
原文
This post was written by Andrew Pardoe, Mark Levine, and Iyyappa Murugandi.
Thank you for your feedback! We’ve made some changes to the layouts based on your feedback.
Update Dec 8 2016 Finding the location of a VC++ install: Some folks have asked about how to find instances of Visual C++ on a developer’s machine. There’s no longer a registry key you can query. If you can launch a VS command prompt, you’ll find that the %VCInstallDir% environment variable points to the root of the VC++ install. If you need to query the install programmatically, you’ll need to query COM to find instances of Visual Studio and VC++. Heath Stewart has written a great blog post on this topic with sample code in many languages.
You’ll see many improvements for C++ developers in Visual Studio 2017 as soon as you load your first project. But some of the changes in the product aren’t so obvious. One in particular might surprise you: we’ve moved where the MSVC compiler toolset is laid out on disk.
Why we moved the compiler toolset
The layout of the compiler tools on the disk in VS 2015 reflects decisions made years ago. When we shipped Visual Studio .NET in 2002, we shipped compilers that targeted only the x86 architecture. The x64 and Itanium architectures had only recently been announced when development of Visual Studio .NET started. The layout of the compiler on-disk reflected a world where x86 was the only compiler you would need.
When we introduced support for the Itanium and x64 architectures we added the compilers where it made sense: in the bin directory. We already had a compiler for x86 in the bin directory, so we added subdirectories x86_ia64 and x86_amd64 for compilers that run on x86 and target 64-bit platforms as well as an amd64 directory for compilers that run on x64.
Unfortunately, it didn’t stop there. We added compilers for ARM. And we added cross-targeting compilers that are hosted on x64 and target x86 and ARM. Eventually we ended up with a directory tree that made little sense. Every time a developer wants to write automation that deals with our compilers they have to write special cases in their scripts for the x86 hosted and targeting compiler. Moreover, this layout limits our ability to do interesting things such as having two versions of a compiler or two different compilers installed side-by-side on the one build machine.
Where the compiler toolset moved to in VS 2017
First, let’s discuss the major parts of the compiler toolset. These are reflected in the top-level directory, e.g., %ProgramFiles(x86)%\Microsoft Visual Studio\2017\Enterprise\VC. (Note that this directory, %VCINSTALLDIR%, changed from its VS 2015 location of %ProgramFiles(x86)%\Microsoft Visual Studio 14\VC.)
- Tools: The tools are what you traditionally think of as the MSVC compiler toolset. This includes the old bin, crt, include, and lib directories and the binaries that are placed in them. These binaries include cl.exe and link.exe as well as header files and link libraries for the Visual C++ runtime.
- Redist: The redistributable directory contains files that can be redistributed by the end developer with the built application. The CRT redistributables are located here, as well as the other runtimes such as those for AMP and OpenMP.
- Auxiliary: The auxiliary directory contains tools and scripts that are not part of the compilation process but are needed to help with various compilation scenarios. These include files like the CppCoreCheckers or the Unit Test libraries as well as the vcvars*.bat scripts used to configure developer environments.
Note that the compiler toolset layout in Preview 5 is just that–a preview. We may end up changing the layout or even the top-level %VCINSTALLDIR% directory depending on feedback and requirements from internal and external developers.
The tools directory
Let’s take a closer look at the Tools directory–the directory contains the compiler toolsets. Unlike in VS 2015, the Microsoft Visual C++ compiler is in a directory called MSVC. If you installed the “Clang with Microsoft Codegen” option, you’ll see a directory next to MSVC called ClangC2 that contains the Clang/C2 binaries.
There’s a subdirectory in the MSVC directory with a compiler version number. For VS 2017 RC, that version number is 14.10.24629. In that directory are the familiar subdirectories from the %VCINSTALLDIR% directory in VS 2015: bin, crt, include, and lib.
We’ve encountered two big differences so far. First, the MSVC directory means that the Visual C++ tools can sit beside another toolset, in this instance, ClangC2. Second, the fact that the tools are versioned inside of the MSVC directory means that we can have multiple versions of the Visual C++ compiler installed on the same build machine. Right now, there’s no simple way to install multiple versions. But we’ve designed the directory structure to make it possible in the future to easily switch between versions of the Visual C++ tools.
Hosts and targets
We find even more changes when looking inside the 14.10.24629\bin directory. While in VS 2015 the x86 toolset was the “standard” toolset and we had directories with names like amd64_arm representing the AMD64-ARM cross-targeting compiler, in VS 2017 these have been split up into directories labelled HostXXX and a subdirectory called x86 or x64. What’s the distinction here?
Let
Let’s pause to define a couple of terms. “Host” refers to the platform that the compiler toolset runs on. “Target” refers to the platform that the compiler builds applications to run on. In the VS 2015 world, amd64_arm included the compilers that were hosted on x64, and targeted ARM. In VS 2017 it’s more structured: all of the x64 hosted compilers live in a directory called HostX64. In that directory we find x86, x64, etc., indicating the target architecture.
The bin directory is the only one with a set of HostXXX directories. This is because the executables need to run on the host. The include directory, which contains only source files, is specific to neither the host nor the target. The lib directory is specific to only the target architecture. Likewise, many of the tools in the Auxiliary directory are specific to the target architecture but not to the host.
Benefits of the new layout
We hope you can see that there are a lot of benefits to refreshing our compiler toolset layout on disk. As Visual C++ grows to include more scenarios like Android and iOS targeting we need to include more compiler toolsets. And as we release our tools more frequently we increase the chance that our developers might want to have multiple versions of the Visual C++ compiler tools installed side-by-side. This new layout is flexible and extensible and should (hopefully!) serve us for many years to come.
As in VS 2015, the Windows SDKs are not installed alongside the Visual C++ binaries, headers and libs. They are installing in the same location under the Program Files(x86) directory. Visual C++ SDKs (such as the DIA SDK) will continue to be installed alongside the VC++ toolset.
Drawbacks of the new layout
Even though change can be good, it’s still change. We know that a lot of people have scripts that are going to break with this layout change. We decided to do this with VS 2017 as we also had to change the top-level directory to accommodate restrictions with the new installer. But any change can be a breaking change.
Please, please, please check out the scripts that you use and make sure you can migrate them to use the new layout. We want to know if you run into any problems. We want to know how hard the migration experience was for your code. Please leave comments on this blog post or send mail directly to our team at visualcpp@microsoft.com.
Finding the default MSVC tools
One last note: a lot of build systems need to find the default version of the Visual C++ tools. When you install Visual Studio it creates a file, %VCINSTALLDIR%\Auxiliary\Build\Microsoft.VCToolsVersion.default.txt, that contains the version string for the default toolset installed with VS. In a typical Preview 5 installation, %VCINSTALLDIR% would point to %Program Files(x86)%\Microsoft Visual Studio\Visual Studio 15.0\Common7\IDE\VisualCpp.
You can parse this file with one extra line and variable in your command script:
Feedback
You’ll see a number of benefits from the new layout of the compiler toolset but we know that a lot of you will have to fix up scripts that you might not have looked at for years. We’re working on making this experience simple and smooth for everyone so please do reach out to us with details of your experience. If you have feedback on any part of this design please let us know in the comments below or by mailing visualcpp@microsoft.com. Thank you!
總結
以上是生活随笔為你收集整理的Visual Studio 2017中的编译器工具布局的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： LwIP 之一 源码目录文件详解及移植说
- 下一篇： USB 之一 USB2.0 规范详解 第