Feedback from an application developer

[Ralf Habacker]

Thomas Friedrichsmeier schrieb:
> Hi,
>
> the remainder of this mail will focus on some things, I'm not happy with, so 
> before I forget, I should write that I am positively surprised by just how 
> well the windows port is working. I really am, and I would like to thank you 
> for your great work!
>
> I am the main developer of RKWard, a KDE application developed outside of 
> KDE's SVN repository. A while ago, I finally started working on a windows port 
> of RKWard, and while there are still some remaining issues, we did release the 
> first "official" version of RKWard on Windows, recently. So we had to find a 
> decent way to create and distribute a windows binary. That turned out to be 
> harder than expected:
>
> 1: Is it possible for external applications to provide a version of the 
> windows installer that is customized to include the external application? From 
> looking here and there, it appears to be designed to allow this, but how? 
This is already done for amarok builds see 
http://amarok.kde.org/blog/archives/1055-Amarok-on-Windows-Get-Your-Nightly-Builds.html
Although this requires to have a copy of all basic libraries on the 
external server.
Another way is to integrate an external site into the installer using 
the @site config attribute. 
http://websvn.kde.org/*checkout*/trunk/kdesupport/kdewin-installer/config-sample.txt?content-type=text%2Fplain

This requires to have a site statement into a config.txt of a kde 
release on www.winkde.org.

1. You may download 
http://www.winkde.org/pub/kde/ports/win32/releases/stable/4.3.0/config.txt 
and save this file in you installer download directory using the name 
config-remote.txt.
2. Try to add a @package definition as already available to this file 
and run installer in package manager mode.
The installer will see the config-remote.txt and will use it instead of 
fetching the related file from the server.
3. You will find your new package in the related category.
4. Then you can add dependencies in the config-remote.txt file using a 
@deps attribute

5. To include a complete external site with several packages you may add 
a @site attribute. In the above mentioned config file all packages are 
under the @site all definition. You may take a look there.

6. If all is ready copy your config-remote.txt to a server.

If you have more questions in this area let me know.

Beside this minor configuration problems there are other important 
things to consider when having packages outside the main kde releases. 
The most annoying stuff are dependencies and binary incompatible 
changes. To avoid this as much as possible we have a complete 
distribution with all dependencies in every release.
 
> Is there any documentation on this?
>   
over the last year several thread about the structure is documented at 
the kde windows mailing list and there are the sources
> 2: Is it possible in the windows installer to query the user for further 
> information 
currently no - there is only an initial support to control the gui of 
external installers, not much tested yet.
> (my package needs another non-KDE library, and needs to install 
> some parts into the directory where this is installed)? 
in the above mentioned configuration example there is a package 
attribute, which can include an package from somewhere outside.

> Alternatively, is it 
> possible to add something like post installation scripts to finish the setup of 
> applications that need more settings? 
there are postinstall scripts possible. An example of such script could 
be found at  
http://websvn.kde.org/trunk/kdesupport/emerge/portage/kde/kdebase-runtime/post-install-bin.cmd?view=markup
The emerge build system adds postinstall scripts - if available - to a 
binary package.

To have binary package for kde on windows there is a tool named 
kdewin-packager http://www.winkde.org/pub/kde/ports/win32/installer/. 
required, which is already interated into the emerge build system. An 
example for operation is shown below:

emerge --package <package>

> Once I had the NSIS installer working, I ran into another unexpected problem: 
> There is this MSVC / MinGW issue. I understand this problem cannot be solved 
> at its root, but is there really no better way of coping with this 
> incompatibility? Right now (correct me, where I'm wrong):
> - *all* kde packages (library or not) in the kde-win installer need to be 
> compiled with both MinGW and MSVC.
>   
This has been already answered
> - both versions are not co-installable 
not true
> (or at least not in the same directory).
>   
yes
> For developers / packagers this means that you either need to specifically 
> instruct users to install one particular flavour of KDE, or you need to provide 
> both versions, even if:
> - nothing links against your package
> - you're already spending enough time compiling / packaging
> - if you need to link against a third party C++-library that's only readily 
> available in one flavour, you're out of luck.
>
> I don't know the technical details, I'm sure you guys have already discussed 
> this before, and most probably this just isn't as easy as it sounds, but: If 
> you could find any way to co-install both MinGW and MSVC versions (of the 
> libraries, only), and to do so automatically, without the user ever needing to 
> worry about this, this would really make packaging third party KDE 
> applications easier.
>   
the most important issue is 
http://qt.nokia.com/developer/task-tracker/index_html?id=157932&method=entry
->  Rejected: We don't find sufficient reason to implement this naming 
scheme.

I guess this can be retried for kde 5

Regards
 Ralf