{"id":10945,"date":"2016-10-07T08:55:45","date_gmt":"2016-10-07T15:55:45","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/vcblog\/?p=10945"},"modified":"2022-05-20T09:33:42","modified_gmt":"2022-05-20T09:33:42","slug":"compiler-tools-layout-in-visual-studio-15","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/compiler-tools-layout-in-visual-studio-15\/","title":{"rendered":"Compiler Tools Layout in Visual Studio 2017"},"content":{"rendered":"<p><a href=\"https:\/\/blogs.msdn.microsoft.com\/c\/2016\/12\/12\/visual-studio-15%E7%9A%84%E7%BC%96%E8%AF%91%E5%99%A8%E6%96%87%E4%BB%B6%E7%9B%AE%E5%BD%95%E5%B8%83%E5%B1%80\/\">\u70b9\u8fd9\u91cc\u770b\u4e2d\u6587\u7248<\/a><\/p>\n<p><em>This post was written by Andrew Pardoe, Mark Levine, and Iyyappa Murugandi.<\/em><\/p>\n<p><strong>Thank you for your feedback! We&#8217;ve made some changes to the layouts based on your feedback.<\/strong><\/p>\n<p><strong>Update\u00a0Dec 8 2016 Finding the location of a VC++ install:<\/strong>\u00a0Some folks have asked about how to find instances of Visual C++ on a developer&#8217;s machine. There&#8217;s no longer a registry\u00a0key you can query.\u00a0If you can launch\u00a0a VS command prompt, you&#8217;ll find that the %VCInstallDir% environment variable points\u00a0to the root of the VC++ install. If you need to query\u00a0the\u00a0install programmatically, you&#8217;ll need to\u00a0query COM to find instances of Visual Studio and VC++. Heath Stewart has written a <a href=\"https:\/\/blogs.msdn.microsoft.com\/heaths\/2016\/09\/15\/changes-to-visual-studio-15-setup\/\">great blog post on this topic<\/a> with sample code in many languages.<\/p>\n<p>You&#8217;ll see many <a href=\"https:\/\/devblogs.microsoft.com\/cppblog\/visual-studio-2017-rc-now-available\/\">improvements for C++ developers in Visual Studio 2017<\/a> as soon as you load your first project. But some of the changes in the product aren&#8217;t so obvious. One in particular might surprise you: we&#8217;ve moved where the MSVC compiler toolset is laid out on disk.<\/p>\n<h3>Why we moved the compiler toolset<\/h3>\n<p>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.<\/p>\n<p>When we introduced support for the Itanium and x64 architectures we added the compilers where it made sense: in the <code>bin<\/code> directory. We already had a compiler for x86 in the <code>bin<\/code> directory, so we added subdirectories <code>x86_ia64<\/code> and <code>x86_amd64<\/code> for compilers that run on x86 and target 64-bit platforms as well as an <code>amd64<\/code> directory for compilers that run on x64.<\/p>\n<p>Unfortunately, it didn&#8217;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.<\/p>\n<h3>Where the compiler toolset moved to in VS 2017<\/h3>\n<p>First, let\u2019s discuss the major parts of the compiler toolset. These are reflected in the top-level directory, e.g., <code>%ProgramFiles(x86)%\\Microsoft Visual Studio\\2017\\Enterprise\\VC<\/code>. (Note that this directory, <code>%VCINSTALLDIR%<\/code>, changed from its VS 2015 location of <code>%ProgramFiles(x86)%\\Microsoft Visual Studio 14\\VC<\/code>.)<\/p>\n<ul>\n<li><em>Tools:<\/em> 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.<\/li>\n<li><em>Redist:<\/em> 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 <a href=\"https:\/\/msdn.microsoft.com\/en-us\/library\/hh265137.aspx\">AMP<\/a> and <a href=\"https:\/\/msdn.microsoft.com\/en-us\/library\/tt15eb9t(v=vs.140).aspx\">OpenMP<\/a>.<\/li>\n<li><em>Auxiliary:<\/em> 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 <a href=\"https:\/\/devblogs.microsoft.com\/cppblog\/tag\/cppcorecheck\">CppCoreCheckers<\/a> or the <a href=\"https:\/\/msdn.microsoft.com\/en-us\/library\/hh598953.aspx\">Unit Test libraries<\/a> as well as the <code>vcvars*.bat<\/code> scripts used to configure developer environments.<\/li>\n<\/ul>\n<p>Note that the compiler toolset layout in Preview 5 is just that&#8211;a preview. We may end up changing the layout or even the top-level <code>%VCINSTALLDIR%<\/code> directory depending on feedback and requirements from internal and external developers.<\/p>\n<h3>The tools directory<\/h3>\n<p>Let\u2019s take a closer look at the Tools directory&#8211;the directory contains the compiler toolsets. Unlike in VS 2015, the Microsoft Visual C++ compiler is in a directory called <code>MSVC<\/code>. If you installed the &#8220;Clang with Microsoft Codegen&#8221; option, you&#8217;ll see a directory next to <code>MSVC<\/code> called <code>ClangC2<\/code> that contains the Clang\/C2 binaries.<\/p>\n<p><a href=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/path1.png\"><img decoding=\"async\" class=\"alignnone size-medium wp-image-10965\" src=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/path1-300x157.png\" alt=\"path1\" width=\"300\" height=\"157\" \/><\/a><\/p>\n<p>There\u2019s 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 <code>%VCINSTALLDIR%<\/code> directory in VS 2015: <code>bin<\/code>, <code>crt<\/code>, <code>include<\/code>, and <code>lib<\/code>.<\/p>\n<p>We\u2019ve encountered two big differences so far. First, the <code>MSVC<\/code> directory means that the Visual C++ tools can sit beside another toolset, in this instance, <code>ClangC2<\/code>. Second, the fact that the tools are versioned inside of the <code>MSVC<\/code> directory means that we can have multiple versions of the Visual C++ compiler installed on the same build machine. Right now, there\u2019s no simple way to install multiple versions. But we\u2019ve designed the directory structure to make it possible in the future to easily switch between versions of the Visual C++ tools.<\/p>\n<h3>Hosts and targets<\/h3>\n<p>We find even more changes when looking inside the <code>14.10.24629\\bin<\/code> directory. While in VS 2015 the x86 toolset was the &#8220;standard&#8221; toolset and we had directories with names like <code>amd64_arm<\/code> representing the AMD64-ARM cross-targeting compiler, in VS 2017 these have been split up into directories labelled <code>HostXXX<\/code> and a subdirectory called <code>x86<\/code> or <code>x64<\/code>. What&#8217;s the distinction here?<\/p>\n<p><a href=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/path2.png\"><img decoding=\"async\" class=\"alignnone size-medium wp-image-10966\" src=\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/9\/2019\/02\/path2-300x97.png\" alt=\"path2\" width=\"300\" height=\"97\" \/><\/a><\/p>\n<p>Let\u2019s pause to define a couple of terms. &#8220;Host&#8221; refers to the platform that the compiler toolset runs on. &#8220;Target&#8221; refers to the platform that the compiler builds applications to run on. In the VS 2015 world, <code>amd64_arm<\/code> included the compilers that were hosted on x64, and targeted ARM. In VS 2017 it\u2019s more structured: all of the x64 hosted compilers live in a directory called <code>HostX64<\/code>. In that directory we find <code>x86<\/code>, <code>x64<\/code>, etc., indicating the target architecture.<\/p>\n<p>The <code>bin<\/code> directory is the only one with a set of <code>HostXXX<\/code> directories. This is because the executables need to run on the host. The <code>include<\/code> directory, which contains only source files, is specific to neither the host nor the target. The <code>lib<\/code> directory is specific to only the target architecture. Likewise, many of the tools in the <code>Auxiliary<\/code> directory are specific to the target architecture but not to the host.<\/p>\n<h3>Benefits of the new layout<\/h3>\n<p>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.<\/p>\n<p>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 <code>Program Files(x86)<\/code> directory. Visual C++ SDKs (such as the <a href=\"https:\/\/msdn.microsoft.com\/en-us\/library\/x93ctkx8.aspx\">DIA SDK<\/a>) will continue to be installed alongside the VC++ toolset.<\/p>\n<h3>Drawbacks of the new layout<\/h3>\n<p>Even though change can be good, it\u2019s 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.<\/p>\n<p><strong>Please, please, please check out the scripts that you use and make sure you can migrate them to use the new layout.<\/strong> 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 <a href=\"mailto:visualcpp@microsoft.com\">visualcpp@microsoft.com<\/a>.<\/p>\n<h3>Finding the default MSVC tools<\/h3>\n<p>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, <code>%VCINSTALLDIR%\\Auxiliary\\Build\\Microsoft.VCToolsVersion.default.txt<\/code>, that contains the version string for the default toolset installed with VS. In a typical Preview 5 installation, <code>%VCINSTALLDIR%<\/code> would point to <code>%Program Files(x86)%\\Microsoft Visual Studio\\Visual Studio 15.0\\Common7\\IDE\\VisualCpp<\/code>.<\/p>\n<p>You can parse this file with one extra line and variable in your command script:<\/p>\n<pre class=\"prettyprint disable-colors\">@rem set BINDIR=get directory for x86-hosted, x86-targeting binaries\r\nset \/P VCTOOLS_VERSION=&lt;\"%VCINSTALLDIR%\\Auxiliary\\Build\\Microsoft.VCToolsVersion.default.txt\"\r\nset BINDIR=%VCINSTALLDIR%\\Tools\\MSVC\\%VCTOOLS_VERSION%\\bin\\HostX86\\x86\r\n<\/pre>\n<h3>Feedback<\/h3>\n<p>You&#8217;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\u2019re 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 <a href=\"mailto:visualcpp@microsoft.com\">visualcpp@microsoft.com<\/a>. Thank you!<\/p>\n<p>&nbsp;<\/p>\n<h3>Known issue<\/h3>\n<p>Update 10\/10\/2016: It turns out that Tools-&gt;Visual Studio Command Prompt can&#8217;t find <code>vcvars32.bat<\/code> when it launches. This issue has been fixed for the next release. In the interim, please launch a developer command prompt from the Windows shell, e.g., from the Start button or by pinning it to your Taskbar.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>\u70b9\u8fd9\u91cc\u770b\u4e2d\u6587\u7248 This post was written by Andrew Pardoe, Mark Levine, and Iyyappa Murugandi. Thank you for your feedback! We&#8217;ve made some changes to the layouts based on your feedback. Update\u00a0Dec 8 2016 Finding the location of a VC++ install:\u00a0Some folks have asked about how to find instances of Visual C++ on a developer&#8217;s machine. There&#8217;s [&hellip;]<\/p>\n","protected":false},"author":312,"featured_media":35994,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[48,140],"class_list":["post-10945","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cplusplus","tag-build","tag-c"],"acf":[],"blog_post_summary":"<p>\u70b9\u8fd9\u91cc\u770b\u4e2d\u6587\u7248 This post was written by Andrew Pardoe, Mark Levine, and Iyyappa Murugandi. Thank you for your feedback! We&#8217;ve made some changes to the layouts based on your feedback. Update\u00a0Dec 8 2016 Finding the location of a VC++ install:\u00a0Some folks have asked about how to find instances of Visual C++ on a developer&#8217;s machine. There&#8217;s [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/10945","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/users\/312"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/comments?post=10945"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/10945\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media\/35994"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media?parent=10945"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/categories?post=10945"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/tags?post=10945"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}