Visual Studio: Fixes for Compilation #773

Merged
merged 10 commits into from Aug 19, 2015

Projects

None yet

7 participants

@micove
Contributor
micove commented Aug 19, 2015

Current status using the VS GUI in Win10.

Legend:
=> In queue for testing.
=> Has build failures.
🔶 => No failures but has skips.
=> No failures or skips.
APR => After Pull Request.

PCSX2_suite.sln

VS2013 Update 5 VS2015 RTM APR VS2013 Update 5 APR VS2015 RTM
Win32 - Debug [1] [1]
Win32 - Debug AVX [2] [2]
Win32 - Debug AVX2 [2] [2]
Win32 - Debug SSE2 [2] [2]
Win32 - Debug SSE4 [2] [2]
Win32 - Debug SSSE3 [2] [2]
Win32 - Devel [3] [4]
Win32 - Release [5] [5]
Win32 - Release AVX
Win32 - Release AVX2
Win32 - Release SSE2
Win32 - Release SSE4
Win32 - Release SSSE3

old_plugins.sln

VS2013 Update 5 VS2015 RTM APR VS2013 Update 5 APR VS2015 RTM
Win32 - Debug [6] [6]
Win32 - Devel [6] [6]
Win32 - Release 🔶 [7] 🔶 [7]

[1] Build: 28 succeeded, 1 failed, 0 up-to-date, 0 skipped (Lilypad fails)
[2] Build: 19 succeeded, 1 failed, 0 up-to-date, 9 skipped (Spu2-X fails)
[3] Build: 28 succeeded, 1 failed, 0 up-to-date, 0 skipped (GSdx fails)
[4] Build: 27 succeeded, 2 failed, 0 up-to-date, 0 skipped (PCSX2 & GSdx fail)
[5] Build: 20 succeeded, 2 failed, 0 up-to-date, 7 skipped (Portaudio & Spu2-X fail)
[6] Build: 19 succeeded, 1 failed, 0 up-to-date, 0 skipped (ZeroGS fails)
[7] Build: 15 succeeded, 0 failed, 0 up-to-date, 5 skipped
Note: x64 is not included in the table because it needs work.

Commit 1

Cherry pick Pistachioman's commit.
Fixes build failures of Release. This case is [5].

Commit 2

7 plugins did not get compiled in the Release target. This case is [5].
Note: Release = "Release SSE2" therefore one of the two could be removed.

Commit 3

Add Debug target for CDVDnull.
It's the only one w/o it. It's based on the Release one but I made sure
to use the correct props and settings.

Commit 4

Debug builds as a whole skipped 45 and used 6 Release targets.

Portaudio was skipped => SPU2-X does not build. This case is [2].
Note: Debug = "Debug SSE2" therefore one of the two could be removed.

Commit 5

It could not find dxguid.lib since it was only available for Release. This case is [1].
I also fixed it for x64 while I'm at it.

This should go on a prop but that is a different PR. Also a tad pedantic but I
would have used AdditionalIncludeDirectories and AdditionalLibraryDirectories
instead of LibraryPath and IncludePath.

Commit 6

Devel uses /MD
Release uses /MD
Debug uses /MDd

Don't mix /MD with /MDd.
This fixes the build failure of GSdx while trying to link to a Release opencl
while Devel compiled a Debug opencl. This case is [3] and part of [4].

Commit 7

I went a bit of trigger happy since compiling so much is not fun. Changes:
Solution
- Remove all SSE2/SSSE3/SSSE4/AVX/AVX2 configurations. Not used.
- Remove wxAdv3.0 and x86emitter. Compiled but not used.
- Make sure Release compiles Release.
- Make sure Debug compiles Debug.
- Make sure Devel compiles Release or Devel.
- Make sure nothing get skipped.
- Do the last 4 for the x64 build.

CDVDolio
- Remove SSE2/SSSE3/SSSE4/AVX/AVX2 configurations. Not used.
- Remove props. Cruft.
- Remove _M_SSE from stdafx.h. Pointless and only reference to it.

xpad
- Remove SSE2/SSSE3/SSSE4/AVX/AVX2 configurations. Not used.
- Remove props. Cruft.
- No reference to _M_SSE.

Only GSdx uses _M_SSE.

Commit 8

Apparently only Debug/Devel ZeroGS require:
 - comctl32.lib
 - RpcRT4.lib
 - pthreads.lib

Commit 9

Removed
- Debug SSE2 (same as Debug)
- Debug SSSE3
- Debug SSE4
- Debug AVX
- Debug AVX2
- Release SSE2 (same as Release)

I also checked the x64 part and made sure no skips and
Debug/Devel/Release used the correct configurations.

GSdx can still be compiled with these debug flavors but requires
to manually select them.

Commit 10

Fix Devel in VS2015.

I was trying to understand the sorcery VS2013 did to make it work.
Adding the missing include fixes it but apparently VS2013 was happy w/o it.

Done. Compilation was slowwwwwwwwwww and boring.

Pistachioman and others added some commits Aug 15, 2014
@yxmline
yxmline commented Aug 19, 2015

The future can not compile with support asio sound card spu2-x plugin ??

@avih
Member
avih commented Aug 19, 2015

I think that Devel is closer to debug than to release, but I'm not sure exactly how.

Devel does have debug symbols, and it doesn't take as long to link/optimize like release, but I think it runs faster than Debug and only somewhat slower than Release.

@gigaherz @sudonim1 , do any of you recall how Devel differs from the Debug and Release configurations?

As for as the variants of Debug and Release (AVX etc), IIRC that's mostly (exclusively?) for GSdx, where it can use different optimization paths depending on CPU capabilities - at compile time.

@avih
Member
avih commented Aug 19, 2015

@micove , you didn't mention which VS version you were using. I tried with vs2013 on win8.1 and both release avx2 and devel worked fine.

On vs2015 on windows 10, release completed but devel had 1 missed symbol for pcsx2-dev.exe (I know you know, but adding it here for reference).

@micove
Contributor
micove commented Aug 19, 2015

@yxmline
It just changes the default target to "NO ASIO" since the ASIO SDK is not included in the folder. If you manually download the asio sdk (which I have never done) then you can manually change it to use ASIO again.

@avih

I put it on the header of the table vs2013 (more specifically update 5 Professional) and vs2015. Unless you mean OS then I'm using Win 10. I will add Update 5 to the table and win 10 to the 1st post too.

Edit: I'm leaving Devel for last since mixing Release and Debug can cause issues sometimes. I have not looked closely at the devel props to understand what it's supposed to be so that is why I asked.

@micove micove Add Debug target for CDVDnull.
It's the only one w/o it.
683c003
@avih
Member
avih commented Aug 19, 2015

I meant which VS version for the tables at the first comment, but I missed the headers... (Thou Shalt Not Comment while tired!)

I guess the windows version doesn't carry too much weight, but nevertheless, it might.

My info that Devel works with vs2013 is also for Pro update 5.

@Pistachioman
Contributor

I'm pretty sure Devel is based on Release, since it's basically just Release without some optimizations. In any case, it's important to not mix debug and release runtime libraries, and Devel uses the Release ones.

@gregory38
Contributor

On linux, Devel is release with debug symbol, less force inline, more print.The purpose of dev is a playable (fps wise) build that can still be debugged.

@micove micove Lilypad: Fix compilation error in Debug target.
It could not find dxguid.lib since it was only available for Release.
.
This should go on a prop but that is a different PR.
.
I also fixed it for x64 while I'm at it.
fd813a0
@micove
Contributor
micove commented Aug 19, 2015

Oh okay, since it's the Devel turn now I just checked and yes both Devel and Release use

<RuntimeLibrary>MultiThreadedDLL</RuntimeLibrary>

Devel also fails in vs2013 it only works if someone builds opencl in Release and then try to build Devel. Due to mixing Release with Debug stuff it was broken. I did a "git undo" before each build so I had a clean environment each time. It also made this more tedious and longer to compile.

.gitconfig

[alias]
  undo = !git reset --hard && git clean -xdf

This basically destroys everything that is not commited so beware.

@micove micove Devel: Don't mix Devel with Debug.
Devel uses /MD
Release uses /MD
Debug uses /MDd
.
Don't mix /MD with /MDd.
69b056e
@avih
Member
avih commented Aug 19, 2015

Devel also fails in vs2013 it only works if someone builds opencl in Release and then try to build Devel.

True. I was so used to the fact that Devel needs first a release build that I didn't try building Devel before Release...

@refractionpcsx2
Member

I see lots of nice tick boxes :) Do you want this merging now or do you want to wait until old_plugins is checked?

@micove
Contributor
micove commented Aug 19, 2015

I have not ticked Devel 2015. It's still building.

@refractionpcsx2
Member

Apologies, it was a sea of tick boxes :P Make sure you can build a devel build from a clean solution, this was always an issue with VS 2013, you had to build a release SSE2 or above then build devel, else it would fail.

@micove
Contributor
micove commented Aug 19, 2015

I already beat you to it and already fixed that :). It was in my previous message or the last commit.

Also Devel still fails in VS2015. My gut feeling is that it's a bug in VS2015 but I want to look at it first.

@avih
Member
avih commented Aug 19, 2015

First, I don't think Debug needs all the build configurations. Devel is SSE2 only (the minimum anyway), so Debug could most probably be the same. I'd imagine the Debug configs might be helpful while developing CPU specific optimizations, but.. see the next point.

As a future step, it would probably make things much more reasonable to maintain (and much less confusing to users) if we had only Debug/Devel/Release configurations, where whatever depends on CPU features can detect them at runtime.

Do we have anything other than GSdx which uses multiple release configs according to CPU caps?

@gabest11 , would that be possible to change the compile time differentiation to runtime? (technically and practically)

@micove
Contributor
micove commented Aug 19, 2015

Yes the only one that uses SSE/SSE2/etc is GSdx. I was going to suggest the same thing about cpudetection since testing 13 builds x2 is silly. Also the Debug build could be just SSE2 which is the default.

I have an unpushed commit to clean up old_plugins.sln since I'm not about to compile them 26 times. When nothing uses SSE4/SSSE/AVX/AVX2.

Edit: Sorry, I'm not about to compile them 52 times. :\

@gregory38
Contributor
 would that be possible to change the compile time differentiation to runtime? (technically and practically

I think It would be a lots of work.

However the number of combination can be reduced
1/ SSE2 for all
2/ SSE4.1 for optimization (few people have a cpu between SSE2/SSE4.1)
3/ AVX2 as AVX1 is not really better than SSE4.1

@avih
Member
avih commented Aug 19, 2015

I have an unpushed commit to clean up old_plugins.sln since I'm not about to compile them 26 times. When nothing uses SSE4/SSSE/AVX/AVX2.

You mean by leaving only debug/devel/release? That makes sense.

@micove
Contributor
micove commented Aug 19, 2015
You mean by leaving only debug/devel/release? That makes sense.

Yes, I wanted to fix Devel VS015 1st before pushing that but I have to leave soon so I might as well finish the old_plugins.

Basically

  • Debug Win32
  • Debug x64
  • Devel Win32
  • Devel x64
  • Release Win32
  • Release x64
@micove
Contributor
micove commented Aug 19, 2015

I mentioned this in my 1st post but it might get lost so I will repeat it.

Currently:
Debug = Debug SSE2
Release = Release SSE2

So one of the two could be removed since they produce the exact same 29 binaries. That should save some tests w/o any compromise since they are the same.

@avih
Member
avih commented Aug 19, 2015

I mentioned this in my 1st post but it might get lost so I will repeat it.

If that was an RFC, go ahead ;)

@micove
Contributor
micove commented Aug 19, 2015

Any preference? I prefer to delete SSE2 and leave the shorter name.

@refractionpcsx2
Member

sounds good to me, there only need to be one debug mode and it should just be debug with as minimal optimization using instruction sets as possible

micove added some commits Aug 19, 2015
@micove micove old_plugins: Remove unused configurations + more.
I went a bit of trigger happy since compiling so much is not fun. Changes:
Solution
- Remove all SSE2/SSSE3/SSSE4/AVX/AVX2 configurations. Not used.
- Remove wxAdv3.0 and x86emitter. Compiled but not used.
- Make sure Release compiles Release.
- Make sure Debug compiles Debug.
- Make sure Devel compiles Release or Devel.
- Make sure nothing get skipped.
- Do the last 4 for the x64 build.
.
CDVDolio
- Remove SSE2/SSSE3/SSSE4/AVX/AVX2 configurations. Not used.
- Remove props. Cruft.
- Remove _M_SSE from stdafx.h. Pointless and only reference to it.
xpad
- Remove SSE2/SSSE3/SSSE4/AVX/AVX2 configurations. Not used.
- Remove props. Cruft.
- No reference to _M_SSE.
.
Only GSdx uses _M_SSE.
6cddd04
@micove micove ZeroGS: Add 61 missing symbols.
Apparently only Debug/Devel require
- comctl32.lib
- RpcRT4.lib
- pthreads.lib
fd78b7b
@micove micove Remove extra debug configurations from sln.
Removed
- Debug SSE2 (same as Debug)
- Debug SSSE3
- Debug SSE4
- Debug AVX
- Debug AVX2
- Release SSE2 (same as Release)
.
I also checked the x64 part and made sure no skips and
Debug/Devel/Release used the correct configurations.
.
GSdx can still be compiled with these debug flavors but requires
to manually select them.
157565e
@micove micove VS2015: Fix Devel. 96df56c
@micove
Contributor
micove commented Aug 19, 2015

Done. The sea of green is complete. I have nothing else to add.

@avih
Member
avih commented Aug 19, 2015

w00t! This round is on me! ;)

So shall I merge?

@micove
Contributor
micove commented Aug 19, 2015

Only issue I can see is that I probably broke the build bot by removing Release SSE2.

@avih
Member
avih commented Aug 19, 2015

Hmm.. good point, and orphis is many times too busy to modify the bot.

That being said, it appears to me it already got broken with the move to universal sln, as its last build is of a4f8c6d which is already yesterday - http://buildbot.orphis.net/pcsx2/

So I don't think merging this PR poses any additional issues, but OTOH we do have a serious issue now that the bot is broken.

So I'm gonna merge, and hope we can get orphis on board quickly enough, and if not, we'll have to reconsider (maybe duplicating the universal sln to the name of the previous sln and somehow restore the some configs? though obviously the solution should be modifying the bot rather than the project to keep satisfying a stale bot)

@micove , any comment on this before I merge?

@avih
Member
avih commented Aug 19, 2015

Another solution to the stale bot issue is maybe just restoring the old sln file. It should probably still be able to build all the configs, even if devs should move to the universal sln in general. It could at least buy us some time until the old sln is no longer compatible with the new code or until orphis moves to the new sln.

@micove
Contributor
micove commented Aug 19, 2015

If orphis is unavailable it should work again by just renaming the sln to pcsx2_suite_vs2013.sln.

I changed the name since it was misleading. It's preferable if Orphis could just rename it in his script since it's a trivial change. But as a last option renaming it in the repo is fine too.

As for this PR, I really have nothing else to say about it. I'm tired of compiling hehe and probably don't want to see it again for a few days.

@avih
Member
avih commented Aug 19, 2015

Yes, understandable, and I agree that the bot should be adapted.

I'll merge as is, and then will duplicate this sln to the old name and see if the bot takes it, else will try to restore the old sln, etc.

Amazing work, thank you very very much! :)

@avih avih merged commit b55d653 into PCSX2:master Aug 19, 2015
@micove
Contributor
micove commented Aug 19, 2015

Heh, I forgot about the "Release SSE2" in my last message. Duplicating the sln using the old name and adding "Release SSE2" to it again should really fix it.

@avih
Member
avih commented Aug 19, 2015

I just talked to Orphis. Hopefully he might be able to handle it in few hours. I'll followup.

@micove
Contributor
micove commented Aug 19, 2015

Oh okay,

I made this just in case:
https://github.com/micove/pcsx2/commits/Revive_Bot

Hopefully it's not needed.

@micove micove deleted the micove:Fixes_MSVS branch Aug 19, 2015
@bositman
Member

Wow loads of work, props for your patience man thanks 👍

@refractionpcsx2
Member

Yeah very good job :)

@avih
Member
avih commented Aug 19, 2015

Buildbot update. Orphis gave me permission to control the bot, and I modified the following:

  • All build targets use the new sln file name.
  • The "Release SSE2" build config was modified to use "Release" instead.

It fails on the first configuration (Release) with:

Compilation error: common\build\x86emitter\x86emitter.vcxproj 

C:\BuildAgent\work\d867cb0ae7aa7219\3rdparty\wxwidgets3.0\include\wx/platform.h(183, 0): error C1083: Cannot open include file: 'wx/setup.h': No such file or directory 

Need to try locally first (only tried Release AVX2 so far locally) and take it from there.

@refractionpcsx2
Member

Slightly off topic but, wow VS 2015 looks like VS2010 lol

Edit: Okay it was just the default settings, felt retro

@avih
Member
avih commented Aug 19, 2015

Edit: Okay it was just the default settings, felt retro

It's to not overwhelm old guys like you with "new" GUI ;)

@refractionpcsx2
Member

So thoughtful :P I have been using 2013 for ages I'll have you know! :P

@micove
Contributor
micove commented Aug 19, 2015

Okay, I found the error. It's weird since this should be an old issue but was never triggered before.

Using a clean environment and trying to just compile x86emitter it will fail. It seems that it depends on wx30Config but that was never added.

The gui always build config 3rd and the emitter 9th. I guess there is some sort of race condition with the parallelization of building projects and the bot builds the emitter before w30Config. Anyway, it should be fixed by adding the dependency.

@avih
Member
avih commented Aug 19, 2015

Do you want to go over all deps and make sure they're correct? if not, we can try first adding this dep and hope there aren't more.

@micove
Contributor
micove commented Aug 19, 2015

Working on it.

I'm checking the 29 projects to see if they are any others too.

14/29 done.

@avih
Member
avih commented Aug 19, 2015

OMG, he's a demon! :p

@micove
Contributor
micove commented Aug 19, 2015

Took longer than expected.

Here:
#776

@refractionpcsx2
Member

Good job! Merged that commit :)

@avih
Member
avih commented Aug 19, 2015

Ladies and gentlemen, we have a lift off! Build bot is operational again! http://buildbot.orphis.net/pcsx2/

One build from just now is already available for download, and another one links now and should be available momentarily. Very good :)

@refractionpcsx2
Member

Good job everybody involved :)

@micove
Contributor
micove commented Aug 19, 2015

Awesome, no more compiling.

@avih
Member
avih commented Aug 20, 2015

I just examined the buildbot logs, and it seems the x86emitter errors happened intermittently also before the move to generic sln, and it just happened to occur also on the first build after we adapted the build bot to the new sln.

The next build, where I (apparently prematurely) declared success was before the fix of the dependency. Then the next build is the latest revision which includes the dependency fix, and it also succeeded.

Hopefully the deps fix will get rid of these intermittent buildbot failures which were there all along.

@avih
Member
avih commented Aug 20, 2015

IGNORE THIS - see next comment.

Another bot build error:

 ..\..\src\hostapi\asio\pa_asio.cpp(115, 0): error C1083: Cannot open include file: 'asiosys.h': No such file or directory
c1xx error C1083: Cannot open source file: '..\..\src\hostapi\asio\ASIOSDK\common\asio.cpp': No such file or directory
c1xx error C1083: Cannot open source file: '..\..\src\hostapi\asio\ASIOSDK\host\ASIOConvertSamples.cpp': No such file or directory
c1xx error C1083: Cannot open source file: '..\..\src\hostapi\asio\ASIOSDK\host\asiodrivers.cpp': No such file or directory
c1xx error C1083: Cannot open source file: '..\..\src\hostapi\asio\ASIOSDK\host\pc\asiolist.cpp': No such file or directory
c1xx error C1083: Cannot open source file: '..\..\src\hostapi\asio\ASIOSDK\common\combase.cpp': No such file or directory
c1xx error C1083: Cannot open source file: '..\..\src\hostapi\asio\ASIOSDK\common\debugmessage.cpp': No such file or directory
c1xx error C1083: Cannot open source file: '..\..\src\hostapi\asio\ASIOSDK\common\register.cpp': No such file or directory 

[MSBuild] 3rdparty\portaudio\build\msvc\portaudio.vcxproj: Build default targets
[21:11:28][3rdparty\portaudio\build\msvc\portaudio.vcxproj] Project 3rdparty\portaudio\build\msvc\portaudio.vcxproj failed.

Another dependency race?

This is weird, I don't see these files either (they appear to be part of the project but they don't exist on disk), and yet building portaudio succeeds locally.

@avih
Member
avih commented Aug 20, 2015

Ignore the above portaudio error.

I failed to realize the bot can also build other branches, and this error happened on another branch which got fixed soon afterwards (after it was rebased to include the sln fixes on master).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment