I am trying to configure my Lumberyard solution. I’ve tried to do this in Lumberyard 1.0, 1.2 and 1.3
There seems to be a critical problem with my msvs or my Lumberyard, and I can’t determine which. Reinstalling and repairing does not fix the problem. In the configure log, this line seems relevant:
Unable to find Visual Studio 2013 for win_x64, removing build target
I need steps to manually fix whatever link is missing between lumberyard and msvs. I have all the stated requirements, followed all the instructions, and all the other forum suggestions.
The solution file is generated, but it has only 1 project (waf-something), and VS fails to load the project when you open the solution.
Yes. I’ve repaired VS, uninstalled, and reinstalled it, re-updated to update 5, installed the C++ runtimes manually, etc. I’ve hacked my way past a few of the failures in the LY source code, only to hit more failures later. (see below)
I have VS Ultimate 2013.
yes
[I will post those logs here in a little while. I’m reinstalling LY atm, because I was trying to dig into the source myself, and I broke more than I fixed. I need to finish reinstalling to get you that log. It will be an un-tainted log, without destructive LY source changes.]
I have built many machines and installed 2013 and 2015 on them without incident. However I was interested in your post and I wanted to replicate your situation as I have have not heard of anyone having this problem. Thinking about it, I don’t think I have never installed 2015 first then 2013, so I built a new clean machine, installed vs 2015 Community and then vs 2013 Community in that order. I downloaded lumberyard 1.3.0.0, ran the setup and configure, built win x64 debug and profile all, and did not have a problem. So at least order of installation seems not to be the issue.
Ah… Reading your latest post is starting to make more sense now. I can understand why you might have had a problem, we do not test lumberyard with a pre-release versions of visual studio. Unfortunately pre-release versions are known to have many little differences with release versions that can cause incompatibilities. Detection of the compiler can be particularly susceptible to failure due to naming differences in the file structure and the registry keys, which is how the lmbr_waf build system detects the compiler installation.
From experience I know pre-release versions can be hard to remove cleanly once installed, they almost always leave behind files that can cause havok on a system. A pre-release version I installed a while back messed up my development system so badly I had to backup my files and reinstall my whole OS. Not anyone’s fault really, just comes with the territory using pre-release software.
Anyway, I’m glad to hear you have resolved your situation. I will make a note of your resolution in case any else has a similar problem we can ask them about pre-release versions.