everest
everest copied to clipboard
project-everest
Add support for building from VS2017
I tried installing just VS2017. It has the ability to install the VS2015 toolchain, so although the IDE is newer, the tools don't have to be.
On a fresh Windows PC. "./everest check" comes close... it expects to find F# version 4.0, but only version 4.1 is installed by VS2017. This can be resolved by downloading F# 4.0 from https://www.microsoft.com/en-us/download/confirmation.aspx?id=48179. It can install after VS2017 without breaking anything.
F# 4.0 depends on msbuild 14, which also isn't installed (error FS0193: Could not load file or assembly 'Microsoft.Build.Utilities.Core, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.)
Installing the Microsoft Build Tools 2015 from https://www.microsoft.com/en-us/download/details.aspx%3Fid%3D48159 resolves that.
The logic in the ./everest script, for setting VS_BIN, doesn't work for VS2017. They refactored out the tools from the IDE, with new directory structures.
- VCToolsInstallDir points to a versioned subdirectory of tools, and bin\HostX64\x64\ contains both cl.exe and ml64.exe.
- VCINSTALLDIR\Auxiliary\Build now contains vcvars.bat and vcvars64.bat.
I think F* works with F# 4.1. Does Vale work with any version of F#? We could just try to detect fsc.exe in the new location.
Does the 2015 version of tools, installed via the 2017 installer, follow the new directory structure or the old directory structure?
I haven't tried Vale using F# 4.1.
The 2015 tools are in a different directory structure than they were in the original VS 2015 install... the assembler is now in the same directory as the C compiler, instead of being in an amd64 directory.
Switching to VS2017 might be something we decide to do as a coordinated effort across Everest projects (Vale, Kremlin, and hence hacl-star and mitls), to avoid having to support multiple styles of VS install.
Yes, I'd be in favor of switching wholesale. Do you need support for the 2015 toolchain as bundled within VS2017 now?
I can't think of a reason why we would want to use the 2015 toolchain. If we stick to 2017, we avoid the hassle of having to dual-target for the two sets of languages (and bugs). Since our code is all-new, we should target the latest VS tools, to get latest security features and performance.
@BarryBo is this still valid knowing that one project you've been working on requires the VS2015 toolchain?
The Docker Windows image (ewerest) is now based on VS2017 and successfully builds, so all of these should work now.
If we have another issue that tracks the creation of a powershell script that fetches and installs VS2017, the right version of python, along with "making the ewerest docker file use that powershell script as a first step", then this one can be closed.
Issue #4 already tracks most of those. Specifically for switching to Python 3.5, I opened issue #54
Guys, Python 3.x is not a good idea as most developer tools assume the 2.x version, including scons.
The API, libs etc are very different between the two versions and even in the industry, Python 3.x has not been popular.
Caroline
From: Tahina Ramananandro (professional account) [mailto:[email protected]] Sent: 31 January 2018 19:22 To: project-everest/everest [email protected] Cc: Subscribed [email protected] Subject: Re: [project-everest/everest] Add support for building from VS2017 (#41)
Issue #4https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fproject-everest%2Feverest%2Fissues%2F4&data=02%7C01%7Cv-camath%40microsoft.com%7Cbd8ef5a34b7648c9648c08d568e00ce3%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636530233852577826&sdata=OdsFWSnOPZpxYVeakDaGXa9UBIGOd8iW0tGqNHoLewE%3D&reserved=0 already tracks most of those: VS 2017 Specifically for switching to Python 3.5, I opened issue #54https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fproject-everest%2Feverest%2Fissues%2F54&data=02%7C01%7Cv-camath%40microsoft.com%7Cbd8ef5a34b7648c9648c08d568e00ce3%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636530233852577826&sdata=gi%2BXnizQm9zWjCTnJwxyxxPuO8SNz6%2B%2FWSrwcNMiJps%3D&reserved=0
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fproject-everest%2Feverest%2Fissues%2F41%23issuecomment-362041457&data=02%7C01%7Cv-camath%40microsoft.com%7Cbd8ef5a34b7648c9648c08d568e00ce3%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636530233852577826&sdata=qHpgPXDo%2FHkw6TmLaZhEwoLjSeyqmVqGy1ZxKzrYKsk%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAh0hfh12JBD9eL5pLMtj-adhi2zQn9Y7ks5tQL1rgaJpZM4OYzto&data=02%7C01%7Cv-camath%40microsoft.com%7Cbd8ef5a34b7648c9648c08d568e00ce3%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636530233852577826&sdata=i1SuSll%2BXb2eH5w0BXkg7h8Dz%2BwMc2gny6cuhcuqjYo%3D&reserved=0.
Caroline, Vale, the one user of scons in our build at present, is already building with Scons 3 and Python 3. Awkwardly, the build machine may still be using Scons 2 / python 2.7, which puts us at risk of build breaks that happen on the build machine but not on our dev machines. Everest is standardizing on Python 3.