KDE Windows and releases

[Shane King]

Ralf Habacker wrote:
> 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 ?

I think getting kdevelop ported would make mingw a bit more tolerable. 
At least we'd get a nice environment with debugger then. Although the 
load times are probably not possible to solve, I think they're likely 
related to embedding debug info in the files vs the .pdb approach of MSVC.

> For the technical decision I have some questions:

I think I can answer these, although someone can correct me if I'm wrong. :)

> 1. Is it possible to use dll's created with Visual Studio 2005 with VS 
> 2008 ?

For C libraries it should be mostly possible (although you can run into 
issues with different versions of the C runtime library).
For C++, there is no binary compatibility.

> 2. Is it possible to use dll's created with Visual Studio 2008 with VS 
> 2005 ?

As above.

> 3. Is it possible to use dll's created with Visual Studio Express 2005 
> with the other versions VS 2005  and VS2008 ?

The express version is the same compiler as the non-express version, 
it's just the GUI environment is missing some features (and with 2005 
you have to download the PSDK seperately).

So VS express 2005 will work with normal 2005, express 2008 will work 
with normal 2008.

> 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)

You can use the express versions for releases if we go with MSVC.

> I personally would prefer the Express versions to not been bound on a 
> license.

IMO if we can't use the expression versions, we have to choose mingw. 
Having to pay for a compiler is not practical for open source projects 
that want to attract participants. :)

> 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.

I guess there's a couple of problems I see with this in the long run. I 
think it's fine for now, but eventually we'll need:

a) A standardised way for people to tell what's already installed by 
some other package and deal with it. Otherwise we'll get into "dll hell".
b) Ideally a simple way for people to integrate with the base package 
system for their own installers. So say I have some app I want to 
package, instead of having to package the base libraries, I should be 
able to rely on something to grab the dependencies of my package from 
the base system.

Maybe this can be handled by allowing the installer to use multiple 
"repositories" like you can with most Linux packagers?

> 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.

That's probably good enough for what we need for now anyway. We can 
build this out with more features as we discover the limitations in it. :)

Maybe some time down the track it would be nice if source packages could 
be split into multiple binary packages (so you have kdelibs and 
kdelibs-dev like on Linux), but that's not really urgent.

The work you're doing in this area is very helpful, I know we don't 
really have enough people to cover everything at the moment and things 
take time. That's why I'm bringing up the subject well in advance of 
when Amarok will actually be wanted to go public. :)

Shane.