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 _______________________________________________ Kde-windows mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-windows
