This is how building for VS2017 works for me... #47
Comments
|
I just saw that my previous text looks a bit garbled, so this is an attempt to upload my version of setVSvars.bat as a text file here, dunno if this works: |
Added missing APIContracts and reorganized them to be more readable and maintainable Enabled running do_vsprojects from an arbitrary folder Fix VS2017 developer prompt changing changing directory and failing the build. Added _DEBUG options to help figure out issues with the builds. Addressing issue #47
|
Thanks @skuskusku. I've cleaned up the build scripts, added support for the 16299 SDK, fixed a couple of issues and pushed out an update. Please try it and I'll merge it into the WinRT branch. |
|
Hello Mr, Khouzam, It builds for all platforms with _WKITS10VER=10.0.15063 successfully and all tests are passed successfully as well. I will try in the next few days with 10.0.16299. Is this branch expected to work with the 10240 SDK as well or isn't it worth a try at all? As a side note: One thing I noticed is that when building from the IDE, the library project files always seem to want recompilation after a successful build. So when attempting to debug one of the test apps, VS will always prompt you to build the libraries again before debugging. This, of course is only a minor annoyance, and I don't know if this ever worked. But in case you can identify this as a regression, maybe you know what needs to be done from memory. Thanks again, -- |
|
Hello Mr. Khouzam, I can confirm that things work as well with the 16299 SDK, all configurations build and test successfully. I tried with the 10240 SDK as well but this failed with 1>.\ms\winrt.cpp : fatal error C1107: could not find assembly 'windows.foundation.foundationcontract.winmd': please specify the assembly search path using /AI or by setting the LIBPATH environment variable With settings for the 10240 SDK, the LIBPATH environment variable is just not set. So if this SDK is intended to be supported, something has still to be done here. Let me know if this is enough information for merging into the main trunk. Greetings, -- |
Hello,
first of all thanks to Mr. Khouzam for his work on the UWP build of openssl. I had some problems getting the VS2017 build working so in case others have the same problem, this is what works for me (see my specs below):
Index: setVSvars.bat
--- setVSvars.bat (revision 9023)
+++ setVSvars.bat (revision 9031)
@@ -29,10 +29,12 @@
call:setVar _VS15VC VisualStudio15VC
if not "%_VS15VC%"=="" (
call "%_VS15VC%\vcvarsall" x86_arm store
call:setVar _VS14VC VisualStudio14VC
call "%_VS14VC%vcvarsall" x86_arm store
call:setEnv
goto :eof
@@ -207,7 +209,7 @@
call:setVar _VS15VC VisualStudio15VC
call:setVar _WKITS10 WindowsKits10.0
call:setVar _WKITS10VER WindowsKits10Version
goto :eof
:end
set _WKITS10VER=10.0.15063
ms\do_vsprojects15.bat
This requires that perl can be located via the PATH environment variable
vsout\openssl.sln
This will fire up VS2017 (unless the .sln extension is tied to a specific version of VS on your computer)
Now build from within Visual Studio 2017. Remember to always set the _WKITS10VER environment variable to 10.0.15063 before firing up a build next time and invoking visual studio to build again. This is the only SDK version that I have found to be working. With this setup, all three platform builds work for me and the tests in the sample apps all pass successfully.
The changes in my patch with the two rem statements look odd and honestly I have no idea why they make things work for me, but I have observed on three machines with VS2017 only that they make things work. Without the first rem statement, the ARM build fails with
'"\vcvarsall"' is not recognized as an internal or external command,
and without the second one, the x64 build (sic!) fails with the same error. Most probably I have overlooked something stupid and obvious, but things work this way.
The last change to the LIBPATH environment variable is what I found is needed for a successful x64 link stage.
Maybe this helps other people to get things working as well. I would be happy if someone has an idea, why the original setVSvars.bat fails with the errors mentioned above so this kludge of mine with those strategically placed :-) rem statements can be replaced with something more meaningful.
Specs: Tested this on three different development machines with either creator's update or fall creator's update. Neither of them had VS2015 installed, all had VS2017 installed. One of the machines had a previous installation of VS2015 installed but removed, but maybe there are some remnants of the VS2015 installation that I am unaware of.
Stefan
The text was updated successfully, but these errors were encountered: