search

xlgames-inc / XLE

XLE -- the "hackable" 3D game rendering engine
MIT License
335 stars 73 forks source link

Canonical Paths for WinSDK (suggested fix) #9

Closed jmkinzer closed 8 years ago

jmkinzer commented 8 years ago

I'm on Windows 10 with VS2015. I encountered a crap ton of compilation errors e.g. in RenderCore_DX11... looks like the approach used in the project files to find the win sdk includes/libs is not valid [for my config]. The problem is the directories now have this sort of structure: image

What I did is simply copy in the settings found in a 'canonical' project (i.e. generated by the VS wizard) and it fixed things right up. For example, for a 64 bit build the windows sdk is found via: Includes = $(WindowsSDK_IncludePath) Libs = $(WindowsSDK_LibraryPath_x64);$(NETFXKitsDir)Lib\um\x64

Not sure if this also works on older VS/SDKs - if it does would definitely be the better approach. Or just assume everyone is now on VS2015 + latest sdk. They should be :-)

djewsbury commented 8 years ago

Thanks, I'll take a look. When I originally set up the projects, it wasn't clear from the documentation how we're really meant to find these directories. The WindowsSDK is normally installs the correct directories in the global properties sheets, I think -- this is how it works on most configurations. However, since the global property sheets can be modified, and the windows SDKs can be installed without using the installer, that approach maybe isn't perfect. They keep changing this stuff every few versions of the SDK, also :). Anyway, the WindowsSDK_XXX macros look good -- I'll take a look at how they can be used.

djewsbury commented 8 years ago

I found that there were some project configuration settings that were overriding the default VS settings, and this is probably the root of the problem. By removing them, it should allow the default VS2015 behaviour to work -- this is good because it will allow "Retarget SDK Version" and other new features to work. And it will now start using the WindowsSDK_XXX macros (which I'm hoping we can assume will be available in all VS2015 configurations).

The configuration files were originally set up for VS2013 and earlier Windows sdks which didn't have those some of that stuff. This change might actually break some VS2013 builds; but I think we are getting close to deprecating that.

Anyway, do you mind checking the latest change in the master build, and seeing if it works with your setup? Thanks!

You might also have to recompile DirectXTex. Just open "Foreign\DirectXTex\DirectXTex\DirectXTex_Desktop_2013.sln" and do a batch build on everything. I'm thinking about a better solution to that problem, also.

jmkinzer commented 8 years ago

I confirm this fixes the issue (allows the default VS2015 behavior) - thanks!

BTW, I always go with 64 bit but for this quick test I compiled under Win32 and noticed a few inconsistencies in the project settings for that config... trivial issue of course: image

djewsbury commented 8 years ago

Great!

Some of the tools projects are actually disabled in Win32 configuration -- but this causes some wierdnesses in Visual Studio. This is done intentionally, because the tools should always be used in 64 bit mode (given that there's no strong reason to limit them to a smaller address space). That's why the project configuration dialog looks confusing in the screenshot.