KDE Windows and releases

[Ralf Habacker]

Shane King schrieb:
> Just had a few thoughts about how KDE is going to work on Windows as a 
> finished product somewhere along the line. For background, my blog post 
> about Amarok Windows releases:
>
> <http://amarok.kde.org/blog/archives/550-Windows-binaries-and-packaging.html>
>
> As I see it, sometime in the not too distant future, Amarok 2 is going 
> to go alpha on Linux, and we'd like to go alpha on Windows too. The 
> difficulty is that you can really only have one KDE 4 installation per 
> user (or at least only be running from one installation at a time), so 
> to play nice with others, Amarok can't really package its own KDE 
> libraries, there needs to be an "official" distribution.
>
>
> For this to happen, I think we'd need to do the following:
>
> * We need to pick a compiler. Keeping things compiling under multiple 
> compilers is a good thing so we can change with circumstances, but for 
> releases to work we need an official compiler.
>
> Lets be honest: MSVC compiles faster, produces smaller binaries, (IMO 
> seems to) produces faster code, has a better debugging environment, is 
> the standard for windows development, just works with the PSDK without 
> having to write your own headers and hasn't had the lead developer quit. 
> On the other hand, the politics of choosing it over mingw are difficult. 
> Not sure how you decide that one, glad it's not my call. ;)
>   
This was discussed already on the KDE on windows meeting this year in 
berlin very intensive

One of reasons why msvc wasn't taken as prefered compiler was that qt 
has no official msvc support. This reason has gone because Trolltech has 
official support for the msvc 2005 compiler.

On more reason against msvc was the hope that big companies would 
sponser further mingw development - Jaruslav: Do you have news about this ?

One reason against mingw was that debugging kde applications with gdb 
would be very hard because of very very long debug info loading time and 
that there is no gui available - is anyone there who can give an update ?

> * We'd need to have sort of nominal release schedule so that we can 
> point people to it and say "yes, bug X is fixed and in the next release, 
> we hope to have it out in 2 weeks". Of course we have very limited 
> resources so we can't commit to anything concrete, but having a vague 
> idea of when the next release is coming and what will be in it would be 
> nice.
>   
For the technical decision I have some questions:

1. Is it possible to use dll's created with Visual Studio 2005 with VS 
2008 ?
2. Is it possible to use dll's created with Visual Studio 2008 with VS 
2005 ?
3. Is it possible to use dll's created with Visual Studio Express 2005 
with the other versions VS 2005  and VS2008 ?
4. Are any side effects known in one of the above mentioned case ?

At least this depends on having people doing this releases which also 
means those people must have a license of the related compiler  (except 
the msvc 2005 Express for which no license is required)

I personally would prefer the Express versions to not been bound on a 
license.
> * Maybe not straight away, but we probably also need a real packaging 
> format (with thing like pre-inst/post-inst scripts etc) so third parties 
> can make packages against the base system. Ideally I should be able to 
> do something like make my own Amarok package and send it out to test a 
> bug fix and others can just install it so long as they have the 
> dependencies installed via the installer.
>   
The basic idea of the KDE on windows packaging system is to have a 
binary packages repository of which people can install their kde 
applications as a whole (which is provided by the currently installer 
even it is not completed for example the command line installer).
This also allows application developers and packagers to use ready 
binary packages as most as possible to concentrate on their specific 
application. For that the repository contains mingw and msvc 2005 packages.

To put their application into this repository they (or the people 
maintaining the common package build system) have to compile it and to 
make a binary package using the kdewin-packager and to send it to the 
repository along with a package descriptor.

 From this repository people can install applications and libraries 
using the installer (it is able to handle multiple installation roots) 
and make their own binary installation tree for a given application from 
which dedicated package could be made using inno setup or nsis or 
something else.

To demonstrate this I have build a snapshot of a single package kate 
installer including khelpcenter. This installer is build up with inno 
setup. The size of the setup is about 11 MB compressed and has an 
installed size of 51 MB.

You can download the setup from 
http://download.cegit.de/kde-windows/other/setup-kate-3.97.1.exe. Please 
note that there may be problems using this snapshot because of the early 
state.

The most annoying and time consuming part is to identify the required 
files but it will be a question of time that the required knowledge will 
be available.

> Is porting something like dpkg or rpm even remotely possible/sensible? 
> Or is it easier to just to a simpler custom implementation?
>   
There is a sort of package manager available as part of the kdewin 
installer, which takes an installed packages and create the related 
archive. There is also a package descriptor concept in work by using a 
specific file for example 
http://download.cegit.de/kde-windows/kde-3.95.1/single/kdebase-mingw.hint.  
(This descriptor file may be added later to the archive to only have one 
file)

Recent kdewin installer versions are able to load and interpret this 
files to setup dependencies and give package information.

I am personally are working on a pre/post-installer script support using 
windows batch files. It  is in an early design phase. If there are 
requirements and/or implementation ideas let me know.

> Now perhaps it's too soon to start thinking about this, 
i think no, it is just in time :-)
> but just like 
> KDE on Unix going to release in part because they hope it will attract 
> interest, perhaps there's merit in doing the same thing on Windows?
>   
yes
> Thoughts? Has this been discussed before in the past and I've missed it? 
>   
partially, see above
> I did a quick google search but it didn't turn up anything quite along 
> these lines.
>
> As I said on my blog post, yay for Linux and someone else having to deal 
> with turning source into binaries. :p
>   
Thank you for your efforts, this is very welcome. :-)



Ralf