Jump to content

Projects/Edu/KStars/Building KStars on Windows: Difference between revisions

From KDE TechBase
Akarsh (talk | contribs)
Akarsh (talk | contribs)
 
(6 intermediate revisions by the same user not shown)
Line 14: Line 14:
Moral of the story: Avoid Cygwin to build. Use MinGW + MSYS.
Moral of the story: Avoid Cygwin to build. Use MinGW + MSYS.


== Initial steps ==
== Resources ==
This article: https://techbase.kde.org/Getting_Started/Build/Windows/emerge is great for almost all things.


This article: https://techbase.kde.org/Getting_Started/Build/Windows/emerge has details on how to set up emerge to get sources and compile them.
If you are using Windows 10, please see the notes at the very bottom of the page
If you are using Windows 10, please see the notes at the very bottom of the page


Also, do not try to use Cygwin to get python and git. The entire process does not want you to have the standard GNU tools in path etc. Instead, get them from the standard installers at python.org and git-scm.com
This article: https://phabricator.kde.org/diffusion/KRITA/browse/master/3rdparty and repo has some great stuff from Boudewijn Rempt of Krita fame amongst other things. Has "shortcuts" to build what is needed and also some docs. However, Krita does not depend on Frameworks KXmlGui and KIO, which KStars depends on, so something must be done about them.
 
This article: http://kate-editor.org/2014/11/30/kate5-on-windows/ , esp. in the comments, has some info on how Dominik built kate on Windows.
 
== Initial steps ==
All above resources have instructions on how to get python and git. Do not try to use Cygwin to get python and git. The entire process does not want you to have the standard GNU tools in path etc. Instead, get them from the standard installers at python.org and git-scm.com


When installing git using the installer from git-scm.com, make sure you choose the option where git is accessible from command line, but the MinGW tools are not added to the path (Second option out of the three as of this writing). Adding the MinGW32 tools to the path ends up causing trouble while building with the MinGW compiler.
When installing git using the installer from git-scm.com, make sure you choose the option where git is accessible from command line, but the MinGW tools are not added to the path (Second option out of the three as of this writing). Adding the MinGW32 tools to the path ends up causing trouble while building with the MinGW compiler.
Line 25: Line 30:
Please note that emerge has a verbose mode (emerge --verbose) which is very helpful for diagnosing any problems.
Please note that emerge has a verbose mode (emerge --verbose) which is very helpful for diagnosing any problems.


== Building Qt packages ==
== Build tools, early dependencies, and Qt packages ==
 
I have partially followed both routes, this means that I already have some dependencies built from using emerge, and some pre-built libraries from the Qt project (http://qt.io) website. Here's what emerge --print-installed lists:
 
wget, 7zip, bin-base, uactools, patch, sed, cmake, subversion, git, putty, mingw-w64, jom, base, zlib, perl, msys, grep, openssl, expat, dbus, mysql-pkg, icu, winflexbison
 
These were downloaded, some compiled, and installed owing to trying to emerge qtbase.


=== Get pre-compiled binaries ===
It seems like one can use the Windows Qt installer from http://qt.io to install the pre-compiled libraries for Windows. Choose LGPL / open source license. Make sure to choose QtQuick and QtSvg since we depend on them. To be "safe" I picked a few more possibly superfluous components.
=== Building from source ===
First build Qt Base by emerging it
First build Qt Base by emerging it


Line 34: Line 51:


This is a very long process. emerge will download 7zip, other developer utils, cmake and then download MSYS (binaries), and then build a few libraries like OpenSSL, libexpat, DBus... from sources, which took about an hour on my system (hardware-assisted emulated Windows with 2 cores / 2GB RAM). Then actually getting to building the Qt libraries.
This is a very long process. emerge will download 7zip, other developer utils, cmake and then download MSYS (binaries), and then build a few libraries like OpenSSL, libexpat, DBus... from sources, which took about an hour on my system (hardware-assisted emulated Windows with 2 cores / 2GB RAM). Then actually getting to building the Qt libraries.
=== Troubleshooting ===
The Qt build failed in my case, but in attempting to re-run to see what the error really was, I had trouble getting past emerge's checking if cmake was installed or not.
The offending lines seemed to be in python script R:\emerge\portage\dev-util\cmake lines containing nightlyVer. It's possible that something changed on the cmake.org website and this script itself needs to be updated.
But since I already had cmake installed, I commented out lines 15-17 and then rehit emerge cmake, and there was no problem.
Continued emerge qtbase. Despite a few errors (patch did not apply), the build continues. The mysterious "DirectX devel kit not found" error that started it all off did not reappear.

Latest revision as of 08:37, 31 December 2015

Introduction

This is an attempt at keeping a log of what needs to be done to build KStars from source on Windows using the emerge tool.

Some quick explanations of GNU on Windows projects

Cygwin: Cygwin provides a kind of emulation layer for UNIX APIs on Windows. It has almost everything of GNU/Linux distros (X11/GNOME/KDE/whatever), including the Qt libraries and KDE Frameworks 5 libraries in its distribution. However, compiling and linking against these libraries means that you are essentially running a binary that uses X and UNIX APIs on Windows. The end result is a KStars binary that needs a running X-server, is very slow, and does not work very well.

MinGW: Provides a native build toolchain for GNU apps on Windows, that does not involve an emulation layer like cygwin1.dll MSYS: Provides a "cygwin-lite" set of Windows GNU binaries so as to have a minimal working GNU system with things like bash etc. This only provides tools, and although they come from cygwin-land, if one compiles with MinGW, it doesn't produce cygwin-binaries.

According to Nicolas Alvarez: If you want to compile a program that uses autotools, you either use cygwin (and get a cygwin binary) or you use mingw to get a native binary, but then you still need the cygwin-ish msys bash to run the ./configure script

Moral of the story: Avoid Cygwin to build. Use MinGW + MSYS.

Resources

This article: https://techbase.kde.org/Getting_Started/Build/Windows/emerge has details on how to set up emerge to get sources and compile them. If you are using Windows 10, please see the notes at the very bottom of the page

This article: https://phabricator.kde.org/diffusion/KRITA/browse/master/3rdparty and repo has some great stuff from Boudewijn Rempt of Krita fame amongst other things. Has "shortcuts" to build what is needed and also some docs. However, Krita does not depend on Frameworks KXmlGui and KIO, which KStars depends on, so something must be done about them.

This article: http://kate-editor.org/2014/11/30/kate5-on-windows/ , esp. in the comments, has some info on how Dominik built kate on Windows.

Initial steps

All above resources have instructions on how to get python and git. Do not try to use Cygwin to get python and git. The entire process does not want you to have the standard GNU tools in path etc. Instead, get them from the standard installers at python.org and git-scm.com

When installing git using the installer from git-scm.com, make sure you choose the option where git is accessible from command line, but the MinGW tools are not added to the path (Second option out of the three as of this writing). Adding the MinGW32 tools to the path ends up causing trouble while building with the MinGW compiler.

Please note that emerge has a verbose mode (emerge --verbose) which is very helpful for diagnosing any problems.

Build tools, early dependencies, and Qt packages

I have partially followed both routes, this means that I already have some dependencies built from using emerge, and some pre-built libraries from the Qt project (http://qt.io) website. Here's what emerge --print-installed lists:

wget, 7zip, bin-base, uactools, patch, sed, cmake, subversion, git, putty, mingw-w64, jom, base, zlib, perl, msys, grep, openssl, expat, dbus, mysql-pkg, icu, winflexbison

These were downloaded, some compiled, and installed owing to trying to emerge qtbase.

Get pre-compiled binaries

It seems like one can use the Windows Qt installer from http://qt.io to install the pre-compiled libraries for Windows. Choose LGPL / open source license. Make sure to choose QtQuick and QtSvg since we depend on them. To be "safe" I picked a few more possibly superfluous components.


Building from source

First build Qt Base by emerging it

emerge qtbase

For some strange reason, emerge may get stuck half way in powershell. It looks like hitting enter periodically ensures that the process goes on (why????). Of course this could just be coincidence but it seems unlikely. (This could be due to a virtualbox feature -- the author of this blurb is running the Windows OS in virtualbox)

This is a very long process. emerge will download 7zip, other developer utils, cmake and then download MSYS (binaries), and then build a few libraries like OpenSSL, libexpat, DBus... from sources, which took about an hour on my system (hardware-assisted emulated Windows with 2 cores / 2GB RAM). Then actually getting to building the Qt libraries.

Troubleshooting

The Qt build failed in my case, but in attempting to re-run to see what the error really was, I had trouble getting past emerge's checking if cmake was installed or not.

The offending lines seemed to be in python script R:\emerge\portage\dev-util\cmake lines containing nightlyVer. It's possible that something changed on the cmake.org website and this script itself needs to be updated.

But since I already had cmake installed, I commented out lines 15-17 and then rehit emerge cmake, and there was no problem.

Continued emerge qtbase. Despite a few errors (patch did not apply), the build continues. The mysterious "DirectX devel kit not found" error that started it all off did not reappear.