Recently found myself wanting the SVN version of Celestia on Windows - looks like the units feature in .ssc/.stc files (which I'm using in my exoplanets add-on) wasn't actually in any released version of Celestia. In case anyone is interested, this is how I managed to do it. (Also putting it here for my reference as well )

Prerequisites

• Microsoft Windows SDK v7.1 (needed for the win32.mak file for building libjpeg)
  Note that this seems to have trouble installing if you have a too-recent version of the Microsoft Visual C++ 2010 redistributable installed, I had to uninstall the redistributable (both x86 and x64), install the SDK, then reinstall the redistributable
• Microsoft Visual Studio 2015 Community Edition (make sure to install C++)
• TortoiseSVN
• Git for Windows
• Something capable of opening .tar.gz files, which incredibly enough still doesn't seem to be built in to Windows
• Patience

Build Qt

Qt 4.8.7 release notes claim to support MSVC 2015, unfortunately they don't appear to distribute the VS2015 version in binary form, and it cannot in fact be compiled as-is under MSVC 2015 either. This StackOverflow question was very helpful here!

• Download Qt 4.8.7 from the Qt download site, you want qt-everywhere-opensource-src-4.8.7.zip
• Extract to a convenient place, I used D:\Qt\4.8.7
• Open VS2015 x86 Native Tools Command Prompt and cd to the D:\Qt\4.8.7 directory (or wherever)
• Download the patch for VS2015 from here. Probably best to give this a quick look-over before applying.
• Possibly there are other tools that will do the job on Windows, however recent versions of TortoiseSVN seem to bail out if they detect they aren't in a repository, so I used git:
  
  Code:
  git apply 02-fix_build_with_msvc2015-45e8f4ee
• Then configure, remember to change prefix to wherever you extracted the archive to
  
  Code:
  configure -platform win32-msvc2015 -prefix D:\Qt\4.8.7 -opensource -confirm-license -opengl desktop -nomake examples -nomake tests -release
• It then says "just run nmake" but I found the compiler ended up running out of heap space every so often, so had to rerun several times
• Copy QtXml4.dll, QtOpenGL4.dll, QtGui4.dll, QtCore4.dll from D:\Qt\4.8.7\lib to Celestia main directory

Download Celestia SVN

• Use TortoiseSVN to do an SVN checkout from svn://svn.code.sf.net/p/celestia/code/trunk

Buiild CSpice

This one is straightforward.

• Download CSpice source code from https://naif.jpl.nasa.gov/naif/toolkit_ ... 32bit.html
• Extract archive, go in the VS2015 x86 command prompt to the directory and run makeall.bat
• Copy cspice.lib to celestia\windows\lib\x86

Build zlib

This one is straightforward, but throws a bunch of errors that can be ignored.

• Download latest source code from http://www.zlib.net/
• Open zlibvc.sln in contrib\vstudio\vc11 (allow it to upgrade the projects)
• Switch to release build, build. Ignore the errors.
• Copy zlibstat.lib from contrib\vstudio\vc11\x86\ZlibStatRelease to celestia\windows\lib\x86 (rename to zlib.lib)
• zlibd.lib can be deleted

Build libpng

The inc files in celestia\windows\inc\libpng are for v1.2 and no longer work with later libpng versions.

• Download latest source from http://www.libpng.org/pub/png/libpng.html
• Update path to zlib source in lpng1622\projects\vstudio\zlib.props
• Open vstudio.sln in lpng1622\projects\vstudio
• Switch to release build, build.
• Copy projects\vstudio\Release\libpng16.dll to Celestia main directory
• Copy projects\vstudio\Release\libpng16.lib to celestia\windows\lib\x86, rename to libpng.lib
• libpngd.lib can be deleted
• Copy png.h, pngconf.h, pnglibconf.h to celestia\windows\inc\libpng

Build libjpeg

This is why we needed the SDK.

• Download latest source from https://sourceforge.net/projects/libjpeg/files/
• Extract the archive, navigate to relevant directory in VS2015 x86 command prompt
• This build depends on the win32.mak in the Windows SDK 7.1. It is not present in later SDKs. Go figure.
  
  Code:
  set INCLUDE=%INCLUDE%;C:\Program Files\Microsoft SDKs\Windows\v7.1\Include
  copy jconfig.vc jconfig.h
  nmake /f makefile.vc
• Copy libjpeg.lib to celestia\windows\lib\x86

Build Lua 5.1

Pretty straightforward

• Download lua 5.1 from https://www.lua.org/versions.html
• From VS2015 x86 command prompt, run
  
  Code:
  cd <directory where you extracted Lua>
  etc\luavs.bat
• Copy src\lua51.dll to main Celestia folder
• Copy src\lua51.lib to celestia\windows\lib\x86 as lua5.1.lib

Build Celestia

The update to MSVC 2015 requires some changes in the source code. Mostly this is adding the <algorithm> header in a lot of places, there's also a couple of other code changes. Patch is attached to this post.

• Save patch file in celestia directory, apply with TortoiseSVN (right click in Explorer, TortoiseSVN Apply patch)
• Navigate to celestia directory in VS 2015 x86 command prompt, add Qt to path, e.g.
  
  Code:
  PATH=%PATH%;D:\Qt\4.8.7
• Build celestia
• Code:
  qmake -spec win32-msvc2015
  nmake release
• Copy the celestia.exe file from the release folder into the main directory
• Run celestia.exe - hopefully it all works...

Concluding remarks

This was a lot more time-consuming and frustrating than the equivalent process in Ubuntu, which involves downloading a bunch of development packages, running qmake then make and you're done. I'm still slightly surprised it works at all.

Hi Andrew,

for the celestia.Sci development in Windows, we feel a certain amount of conservatism may be wise. Hence we still favor VS2013 over VS2015. Yet, we do need Qt5.x, since a number of important features are just not available yet under Qt4.x. Qt5 does need a number of structural modifications in the code, since quite a number of classes and methods were rearranged, eliminated or newly introduced.

Both Qt5.4.2 and Qt5.6 are solid versions. Qt5.6 even receives longtime support. But Qt5.6 has a problem with Intel on-board graphics HD 3000 which therefore has been officially blacklisted. I found however out how to "un-blacklist" Qt>=5.6 without recompiling. Then simple patches in the .Sci code are enough to end up with a stable Qt5.6 version for Windows (32bit). HD3000 graphics is NOT blacklisted for Linux (openSuSE 3.2), MAC OS or external graphics cards. The building works smoothly there at 64bit. Of course with your valuable studies of the third party libs we should really attempt building celestia.Sci & Celestia also for Windows in 64bit.

I wonder why you build the Qt libs yourself, given that it takes a loo...ong time and given that there is a very convenient maintenance kit for all binary versions (Qt Online Installers). Download from here for OS of your choice:

http://www.qt.io/download-open-source/

Notably for Dev work it is very handy, since with a click in qt-creator, one can switch this way between a range of different Qt versions.

Fridger

_________________

I had checked that, from what I could tell it was only supplying Qt5 versions. Maybe it would be easier to upgrade the Celestia SVN source to Qt5 than rebuilding Qt4, not sure.

It's very annoying that Microsoft tends to hide away the previous versions of their compilers when the next one comes out. In any case, I don't have too much space left where I can install another Microsoft compiler (since they seem to require being installed on C:\), at least until I sort out getting a larger SSD.

I recall I tried making a 64-bit version back in the day, from what I remember I didn't manage to compile the gettext versions, which is particularly frustrating when their documentation basically laughs at you for even considering using Windows. (Woe32, so hilarious )

Indeed the units ought be removed in order to get your exo stc/dsc working. Do you have planned the sharing of the exe/dlls for external test of the new units' features? (whether I've not misunderstood the aim at which you were facing in set up the SVN)...

_________________
Never at rest.

Regarding making binaries available, I'm not entirely sure what my options are for doing that and complying with various licenses, particularly since I'm using a patched version of Qt (and would then have to determine exactly what the terms are for distributing the patch).

In order to get something I could make available as binaries, I'd probably have to further update Celestia SVN to use a Qt5 version that's compatible with MSVC 2015, so would not have to worry about the various issues with distributing patched Qt. If Fridger and collaborators are ok with me doing that I could take a look into making the updates and if it works, put code and relevant binaries somewhere, e.g. on GitHub, but obviously would not want it to be a distraction from upcoming Celestia.Sci releases.

related but might be a tangent

isn't Microsoft trying to get EVERYONE to use Windows 10 Universal C Runtime ?

_________________
"I don't pitch Linux to my friends, I let Microsoft do that for me."
Using OpenSUSE 42.1 & Scientific Linux 6.7

I do not think that such a 2015 set-up will work on XP 32 anymore, and this is my last Win OS before to switch definitely on Linux once celestia.Sci will be released. So, this was the cause of my request, because the exe/dll maybe would works, instead. Anyhow, yes on not sharing, I'll stay tuned about your efforts in matter.

_________________
Never at rest.

But wouldn't it be way easier (licensewise) to pull eventual patches into the code rather than patching a standard Qt4 library ?


How about a brilliant alternative option : you just decide at last to join the celestia.Sci dev team ?? There are so many things to do where you are a longstanding expert!
And -as I emphasized above, celestia.Sci is working very well with the recommended Qt5 libraries (Qt5.4.2 and Qt5.6.0). The Qt-based GUI code of .Sci is meanwhile widely different compared to Celestia.SVN. The cooperation of Qt5 and VS2013 (at least) is fine.

On the other hand, a mere porting of Celestia.SVN to Qt5 is really not difficult and follows a few clear-cut rules that are explained in the official Qt4->Qt5 porting documents... Of course, I would be not so happy if we'd start entering into something like a "multi fork" mode.

Cheers,
Fridger

_________________

Thanks Andrew for your initiative and efforts

Because Microsoft indeed hide away the previous versions of their compilers, I was not able anymore to build a new SVN on my new laptop for a while. Previous year I started with Windows 8, but meanwhile it's already upgraded to Windows 10.
So this thread was very welcome to me...

However I already get stuck in the first SDK installation.
The SDK v7.1 asks for a .NET installation, which is already (in another kind of version as stated in the error window) installed on my computer, so it refuses to install.
Also a new .NET 4.6.2 installation (in a try to circumvent the problem) refuses to install

Now I found SDK 10.0.10586.212.
Before going into deeper and deeper problems here, is there any reason to expect this SDK 10 version will work with the rest of of your installation instructions?


Marco

i used to build it using MinGW

it really was much easier than using visualstudio

using Mingw might be an option

_________________
"I don't pitch Linux to my friends, I let Microsoft do that for me."
Using OpenSUSE 42.1 & Scientific Linux 6.7

Apologies for the delay in replying, have been busy with "real life" stuff.

I didn't bother installing any of the .Net stuff with the SDK, just C++-relevant bits, maybe I can check again. Getting it to install is rather annoying because it will fail if it detects later .Net 4.0 versions (probably including .Net 4.5/4.6), but for just C++ stuff I could get away with doing an uninstall of the Microsoft C++ 2010 runtime before, then reinstalling afterwards.

I tried MinGW but ran into an odd issue where it dropped the compiler name out of the command lines if I tried using pkg-config, so didn't play around with it too much.