[lharms]

So last night I gave vs2015 a try with kodi.

I followed the instructions on the wiki. Let it download a bunch of stuff and compile a bunch of stuff. All of that worked just fine.

Then I launched the sln file inside of vs2015. It converted the file nice enough. It set the SDK to the latest version.

After chasing down a bunch of rather odd errors. I stopped for a moment and undid all of my changes. I then went into the project settings and set the platform toolset to be v120 on all of the projects.

That let everything compile. But then it did not link. So something is wrong with my install of visual studio (likely), the installer did not create the "Microsoft Visual Studio 12.0/vc/lib" directory correctly. I was missing all of the libc*.lib/pdb files. Which as you can imagine made things not link correctly. After copying the files from an old vs2013 install.

One thing that I found a bit odd was the effects11 project does not seem to have the XBMC.defaults in it.

Got it all the way to the point where I could step into the code. Not sure if it would 'run' or not. I got sleepy

So basically I got it to compile by putting it into a 2013 mode.

[lharms]

Yeah!!! it ran. Not too surprising as it is basically using the 2013 compiler chain at this point and that works. The two issues I want to dig into are even still there and I got them to happen with the debugger going (improper sorting with sorttokens, and a br-iso playback skipping issue).

Dont get too excited. I started off with the 2015 compiler chain and ran into an interesting issue with the FILE declare MS used to use. It is now 'opaque' in compliance with some ISO standard. In the older SDKs you could see what was in the structure. The new one just has a 'placeholder' pointer. Meaning they do not want you digging thru the FILE structure. Kodi does quite a bit of that. It looks like there is a define flag for something to sort of fix it. But it seems the posix flag means 'not windows'?

I also ran it thru the built in analyzer. It showed 984 warnings. I am sure many are bogus but they may be worth looking at. The few I have looked at are questionable at least. Seen a few places if you end up in an error condition it could end up using a garbage variable.

[lharms]

Had a bit of time today to mess with this. 2013 mode is not enough for me

I compiled each project as 2015. Starting with the 2010 sln file and converted it to 2015 style.

A few expected errors.

Had to add #include <iterator> to GUIDialogVideoInfo.cpp and RepositoryUpdater.cpp for std::back_inserter.

In the Effects11 library I changed static void* __cdecl operator new(_In_ size_t s, _In_ CDataBlockStore &pAllocator) to use inline on both the new and delete. The upstream project looks like it has already done this.

In the UnrarXlib project I moved all of the some of the std*.h includes (especially stdio.h) above Platformdefs.h in os.hpp otherwise you get the new error the sdk introduced of not letting you redefine snprintf. Makes sense you typically want the base compiler includes to be above yours. Not always possible but you want to strive for it.

This is an odd one in HTTPPythonWsgilnvoker.cpp had to cast second parameter call to addWsgiEnvironment. Not sure why it is not working. It is just passing a pointer around. Error c2664.

Now the big one... emu_msvcrt.cpp This guy likes to dig around inside of the FILE struct. In the newest windows SDKs that structure is now opaque. I have not figured out a good fix yet. I just commented everything out that breaks the compile. Obviously the whole system will not run very well . I am thinking something more along the lines of a std::map instead of the for loop lookup to decide if a file is virtual or not. In he .h file I had to basically disable the IS_VALID_STREAM macro. Looks like other platforms are not very tolerant of it either.

At this point all of the cpp/.h files compile. Nothing links. As the project uses externally downloaded pre compiled libraries. Get a few hundred errors sort of like this "CrossGuidd.lib(guid.obj) : error LNK2038: mismatch detected for '_MSC_VER': value '1800' doesn't match value '1900' in AddonCallbacks.obj". But basically older visual studio compiled C++ libs can not be used with newer c++ compiled objects. So that means getting anything compiled with the older visual studio recompiled.

Started with libbluray. Found the instructions inside of the 7z file miss that you need the freetype, and apache ANT. The freetype library is 2.4.6 from ~2010. The wiki calls out 2.6.6-1. But the download page for it only has up to 2.6.2. Had to remove the snprintf/restrict defines from headers_fixup.h provided in the .7z download. Which I now realize is the wrong lib to start with. Should actually read the errors they are trying tell me something

[tester100]

Hi lharms

I am just wondering if you could post some updates or mini-steps of what you have done.

I have been playing around with latest git 16x version and i cannot build it even on visual studio2013 with update5 its using /4.0/v120 i have setup all projects of kodi with that path for that compiler.

but still kodi latest version source is looking for vs2015 /4.0/v140 or toolset 14.0

i have not yet updated or neither installed vs2015 on this machine do not want to mess up things on it.

maybe if you post some steps build up for 2015 i will give it a try and install vs2015 express comunity version.

[lharms]

If you are using the 16x branch and vs2013 these steps should work for you http://kodi.wiki/view/HOW-TO:Compile_Kodi_for_Windows

This will not do much for what you are seeing as this is specific for 2015 not 2013. For vs2015 just to get it to act like vs2013 I followed those steps (steps 3-6). Then once I opened the sln file it converted the sln file to 2015 format. Then for each of the projects I right clicked on properties and changed the platform toolset back to 'Visual Studio 2013 (v120)'.

The big step in getting it to compile is to make sure you have all the libs downloaded and compiled. That comes from the DownloadBuildDeps.bat, DownloadMingwBuildEnv.bat, and make-mingwlibs.bat batch files. If you are using the top most master then it will probably download vs2015 static libs.

Now if you are using the front most master I do not think it will compile under vs2013 anymore either. It probably could but they have updated the tool chains and libs. There is probably little reason to make it work under both 2013/15. I have not touched it for a few weeks so I am still on the older toolchain set. https://github.com/xbmc/xbmc/pull/9588 you can see in there how they got a bit sidetracked and talk about 2013 no longer working.

Good news is vs2013 and vs2015 should co-exist if you have the space for it. I have not tried it. So you may want to spin up a VM and give it a shot so you dont mess up your default build env.

If you want to compile 16x you will need to tell git to change the branch it is on. 'git checkout' I believe is the command you want if you want to do that.

Also I am not sure but I think they are planing to get rid of the default sln file in favor of using cmake to create the sln file?

[tester100]

If you are using the 16x branch and vs2013 these steps should work for you http://kodi.wiki/view/HOW-TO:Compile_Kodi_for_Windows

This will not do much for what you are seeing as this is specific for 2015 not 2013. For vs2015 just to get it to act like vs2013 I followed those steps (steps 3-6). Then once I opened the sln file it converted the sln file to 2015 format. Then for each of the projects I right clicked on properties and changed the platform toolset back to 'Visual Studio 2013 (v120)'.

The big step in getting it to compile is to make sure you have all the libs downloaded and compiled. That comes from the DownloadBuildDeps.bat, DownloadMingwBuildEnv.bat, and make-mingwlibs.bat batch files. If you are using the top most master then it will probably download vs2015 static libs.

Now if you are using the front most master I do not think it will compile under vs2013 anymore either. It probably could but they have updated the tool chains and libs. There is probably little reason to make it work under both 2013/15. I have not touched it for a few weeks so I am still on the older toolchain set. https://github.com/xbmc/xbmc/pull/9588 you can see in there how they got a bit sidetracked and talk about 2013 no longer working.

Good news is vs2013 and vs2015 should co-exist if you have the space for it. I have not tried it. So you may want to spin up a VM and give it a shot so you dont mess up your default build env.

If you want to compile 16x you will need to tell git to change the branch it is on. 'git checkout' I believe is the command you want if you want to do that.

Also I am not sure but I think they are planing to get rid of the default sln file in favor of using cmake to create the sln file?

Hi thanks

i gave up with 2013 cause it only have buildtools 12.0 and v120 and the file source code from git is looking for 2015 with 14.0 v140

so i am now installing the express comunity 2015 on my system also and eventually it will build up correctly i checked the XBMC for windows.sln file and its talking about 2015 so i will give it a try with vs2015 now.

also the build.bat file says the same thing file not found v140 14.0 missing.

[Memphiz]

you have obviously not checked out the jarvis branch - see https://github.com/xbmc/xbmc/blob/Jarvis...indows.sln - jarvis needs vs 2013 - master needs vs 2015