Experimental SDL/SDK branch: Issues with two packaged DLLs

[Vezzra]

When I tried to create an installer package of a test build of the SDL branch today, I got errors when I tried to launch the game after installing that experimental package on a test system. The game complained that OpenAL32.dll and wrap_oal.dll were not valid windows files. As I've of course been using the new experimental SDK, I checked these DLLs and indeed, they were different from the ones in the current SDK. When I replaced the DLLs with the ones from the current SDK, everything worked.

@Geoff: Any idea what's wrong with these DLLs in the new SDK? Judging by the modification timestamp of the DLLs, you've obviously used newer versions (probably build them yourself). Maybe they got somehow corrupted when you made the SDK package...?

I also had to adjust the NSIS installer script to all the new dependencies (SDL replacing Ogre, new boost version, new png library version). These changes have already been committed.

[Geoff the Medio]

I think similar OpenAL issues have come up before...

viewtopic.php?p=49036#p49036

I don't remember if I built or just downloaded the versions in the SDL SDK.

[Geoff the Medio]

I don't remember if I built or just downloaded the versions in the SDL SDK.

looking at the dependencies build folder, it looks like I just downloaded the OpenAL redistributable and got the appropriate files from it. If other versions work better, feel free to update the SDK with them...

[Vezzra]

it looks like I just downloaded the OpenAL redistributable and got the appropriate files from it. If other versions work better, feel free to update the SDK with them...

I did some tests, and apparently depending on what Windows system you run the "oalinst.exe" from openal.org to install the OpenAL DLLs you get different DLL files. When I ran oalinst.exe on my VM with Win7 (64 bit system), it installed the same DLL files you apparently put in the new SDK. When I ran the same installer on my XP machine (32 bit system), I got slightly different DLL files (a bit smaller), they look like the ones in the current SDK.

My guess is, that the oalinst.exe installer checks which system it is run on, and depending on that installs 32 or 64 bit versions (considering that, OpenAL32.dll having this "32" in it's name is a bit deceiving of course). Guessing further that you run on a 64 bit Windows and just downloaded oalinst.exe and ran it, then pulled the OpenAL32.dll and wrap_oal.dll it installed on your system, you ended up putting the 64 bit versions of these libraries into the new SDK. A 32 bit XP will of course complain about those.

Anyway, I took the DLL files oalinst.exe installed on my XP machine, repackaged and uploaded the experimental SDL SDK (FreeOrion_VS2010_SDK_Dec_2014_in_prep.zip). I put the old version into the "Old Versions/Win" folder.

Three pitfalls I ran into when I tried to test the experimental SDL SDK, which might be confusing for people who want to try it out:

• When running a svn update on the FreeOrion folder to pull the sources from the repo, trunk is downloaded. You need to switch to the SDL branch first, otherwise building will, well, fail spectacularly...
• When you load the MSVC solution for the first time, you need to switch to the "Release" build configuration before building. Default is "Debug", and if you try to build that, you will also fail spectacularly. Apparently you only adjusted the "Release" build configuration to the SDL branch.
• vcredist_x86.exe isn't included in the SDK, so you have to copy it to the right place in the directory structure before you run the NSIS installer script. Although that problem also applies to all the other SDK versions AFAIK - is there a reason why you never included it?

Do you want to leave things as they are, as it's only an experimental version, or should we do something about one or more of these issues...?

[Geoff the Medio]

It is still a branch, so I don't see an issue really... Unless you want to move everything to github, since it's apparently the popular place to host code now.

You can remove the debug config, as is the case in trunk.

The SDK assumes you have the compiler to use it installed, so won't need the redistributable installer as well.

[Vezzra]

It is still a branch, so I don't see an issue really

Ok, just wanted to check.

Unless you want to move everything to github, since it's apparently the popular place to host code now.

Sorry, I'm a bit confused - what has that got to do with the issues I mentioned...?

Not that I think the the idea itself isn't worth considering. I've read up a bit about git and how it works, and to me it looks like it would be better suited than subversion/sourceforge for a project like ours. The flexibility when it comes to the whole business of branching is compelling IMO, not to speak of the fact that, from what I've seen, several of our contributers work with git anyway.

Of course, doing that switch would be quite an effort, and then there is the problem that someone we, ASFAIK, never have been able to contact or identify has already set up a "freeorion" organization and repo at github. Apparently there is nothing we can do about that, as, IIRC, Marcels attempts to contact the account holder failed, and github won't let us seize control of the account (you probably remember, that came up back when sourceforge changed the URLs for access of the repos, and consequently the github mirror stopped working).

You can remove the debug config, as is the case in trunk.

Ok, I'll keep that in mind. I admit being too lazy to do the whole packaging and uploading thing just for that, but if and when another update is due and I end up being the one doing it, I'll try not to forget this and include it

The SDK assumes you have the compiler to use it installed, so won't need the redistributable installer as well.

Ah, I see. Well, the problem is, the NSIS installer script looks for the redistributable installer in a certain place, and that's not where it is when you install MSVC Express. When I set up my Windows dev environment for FO and installed MSVC, the redistributable installer did not come with it. Judging by the documentation I consulted then it should have, but wasn't, so I guess something went wrong... still, I tried several times over, and never got it. I had to download it manually. So it might be a good idea to include it in the SDK nonetheless.

[Geoff the Medio]

Unless you want to move everything to github...

...what has that got to do with the issues I mentioned...?

You complained about how SVN branching / updates work.

So it might be a good idea to include it in the SDK nonetheless.

Most people building from the SDK won't be making installers... I don't think it's necessary to include the MSVC redistributables.