KDE Windows and releases

[Saro Engels]

Ralf Habacker schrieb:
> 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 ?
It was basically my idea - and I think it is still a valid thing we 
should talk about. We all know that mingw isn't the best compiler though 
it works and is the only free compiler we have.
We had a big discussion whether or not to support which compiler - in 
the end we said that we use mingw for political reasons and msvc for 
fastness sake. We will not recommend any compiler yet, so development 
should be definitely made with both compilers - we are providing 
packages for both compilers as well. And I don't think that will change 
until either mingw dies (which is the current option) or mingw 
_releases_ a new 4.x compiler which will make it possible to work 
further with it and which might solve some problems we currently have.
> 
> 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.
>>   
This is currently underway - I am building and packaging for mingw every 
week and if I can get some support next year, we might be able to do 
that for both compiler chains.

> 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.
> 
We introduced a custom format already which has already some 
restrictions - and I am sure the difference to rpm etc. gets smaller and 
smaller (in complexity).

>> 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
We already do that - those packages we don't have ported won't get 
released - and these are probably most of the KDE applications.
>> 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
> 

regards
SE