Windows/Packaging: Difference between revisions

From KDE Community Wiki
(Add another quick-and-dirty option)
 
(11 intermediate revisions by 6 users not shown)
Line 1: Line 1:
= Packaging / Distributing KDE applications for Windows =
= Packaging / Distributing KDE applications for Windows Overview =
 
== Overview ==


Currently, several approaches exist towards packaging KDE applications for Windows, and we will try to outline each approach and the steps involved. Which approach (or approaches) you chose will depend on the type of your application, and your personal taste. The main benefits and drawbacks of each approach are listed in the respective sections.
Currently, several approaches exist towards packaging KDE applications for Windows, and we will try to outline each approach and the steps involved. Which approach (or approaches) you chose will depend on the type of your application, and your personal taste. The main benefits and drawbacks of each approach are listed in the respective sections.


Note that the approaches are not mutually exclusive, and in particular it is probably always a good idea to provide an emerge script.
Note that the approaches are not mutually exclusive, and in particular it is probably always a good idea to provide an emerge script.
= Distributing as source =


== Emerge ==
== Emerge ==


[[Getting_Started/Build/KDE4/Windows/emerge | Emerge]] allows to build KDE, and assorted other software on Windows from source, very easily. If you are developing KDE apps on Windows, you are probably familiar with it, already (and if you are not, you better take a look). Emerge also forms the basis for package building for the [[#KDE windows installer]].
[[Getting_Started/Build/Windows/emerge | Emerge]] allows to build KDE, and assorted other software on Windows from source, very easily. If you are developing KDE apps on Windows, you are probably familiar with it, already (and if you are not, you better take a look). Emerge also forms the basis for package building for the [[#KDE windows installer]].


=== Advantages ===
=== Advantages ===
Line 30: Line 31:
Take a look at the existing emerge scripts in portage. Probably there is already a project with a similar setup, so you can copy most things.
Take a look at the existing emerge scripts in portage. Probably there is already a project with a similar setup, so you can copy most things.


= Distributing as binaries =


== KDE windows installer ==
== KDE windows installer ==
Line 57: Line 60:
# ???
# ???
# Profit
# Profit
== Quick and dirty pack ==
You can simply zip up the files needed for your package, and tell your users to unpack them in the KDE installation root.
=== Advantages ===
* Should be real easy for you create.
=== Disadvantages ===
* You'll have to make sure your users understand the fine points, e.g. using the correct type of KDE installation, installing in the correct directory, etc.
=== Procedure ===
* Use
<syntaxhighlight lang="text">[mingw32-]make install DESTIR=Some\temporary\folder</syntaxhighlight>
* Zip up Some\temporary\folder (should contain at least a "bin"-subdirectory).


= Distributing as binary including KDE =


== Installation bundle ==
== Installation bundle ==
Line 81: Line 104:
See http://lists.kde.org/?l=kde-windows&m=127499109727979&w=2 .
See http://lists.kde.org/?l=kde-windows&m=127499109727979&w=2 .


= Custom binary installers =


== Custom (NSIS) installer ==
== Custom (NSIS) installer ==
Line 93: Line 118:


* Considerable effort to create and maintain the installer
* Considerable effort to create and maintain the installer
* NSIS code is ugly! Danger of burning your eyes. Peek at it through your fingers, never look at it directly.


=== Procedure ===
=== Procedure ===


* Your installer should write its own [[../windows_specific_features#kde.conf|kde.conf]] file on installation, to separate your (KDE) settings from other possible installations on that system
* There is a NSIS package base in emerge that can be used to generate a NSIS package directly from emerge. For examples on NSIS packaging check the emerge/portage/package files.
* For documentation on NSIS, see http://nsis.sourceforge.net .
* For documentation on NSIS, see http://nsis.sourceforge.net .
* One NSIS template is discussed at http://lists.kde.org/?l=kde-windows&m=127569323809833&w=2 .
* One NSIS template is discussed at http://lists.kde.org/?l=kde-windows&m=127569323809833&w=2 .


 
= Further info =
== Quick an dirty pack ==
* [http://qt-project.org/doc/qt-4.8/deployment-windows.html Deploying a Qt Application on Windows] (qt-project.org)
 
You can simply zip up the files needed for your package, and tell your users to unpack them in the KDE installation root.
 
=== Advantages ===
 
* Should be real easy for you create.
 
=== Disadvantages ===
 
* You'll have to make sure your users understand the fine points, e.g. using the correct type of KDE installation, installing the the correct directory, etc.
 
=== Procedure ===
 
* Use
<code>[mingw32-]make install DESTIR=Some\temporary\folder</code>
* Zip up Some\temporary\folder (should contain at least a "bin"-subdirectory).

Latest revision as of 14:58, 18 March 2016

Packaging / Distributing KDE applications for Windows – Overview

Currently, several approaches exist towards packaging KDE applications for Windows, and we will try to outline each approach and the steps involved. Which approach (or approaches) you chose will depend on the type of your application, and your personal taste. The main benefits and drawbacks of each approach are listed in the respective sections.

Note that the approaches are not mutually exclusive, and in particular it is probably always a good idea to provide an emerge script.


Distributing as source

Emerge

Emerge allows to build KDE, and assorted other software on Windows from source, very easily. If you are developing KDE apps on Windows, you are probably familiar with it, already (and if you are not, you better take a look). Emerge also forms the basis for package building for the #KDE windows installer.

Advantages

  • Allows building from source, easily
    • Users can use different compilers / settings
  • Excellent for developers and power users
  • Basis for KDE windows installer packages

Disadvantages

  • Compilation takes a long time
  • Not really suited for end-users
  • Compilation is broken at times (latest build status)

Procedure

Warning

This section needs improvements: Please help us to

cleanup confusing sections and fix sections which contain a todo


Does documentation exist? Write it/link it!

Take a look at the existing emerge scripts in portage. Probably there is already a project with a similar setup, so you can copy most things.


Distributing as binaries

KDE windows installer

The KDE windows installer is the officially recommended way for end-users to install the KDE SC, in whole or in part.

Advantages

  • Full package management, including various packages, sources, headers.
  • Includes update capabilities
  • Downloads / installs only what is needed
  • Great if user wants to install a whole collection of KDE apps.

Disadvantages

  • Centralized? If your package is not part of the official KDE SC, you'll have to nag someone to get it into the installer.
  • More complex than most other windows installers.
    • Arguably too complex for some end users.
    • Cumbersome esp. if user wants to install only one specific KDE app.
  • Needs internet connection

Procedure

Warning

This section needs improvements: Please help us to

cleanup confusing sections and fix sections which contain a todo


Does documentation exist? Write it/link it!
  1. Write an emerge script for your app
  2. ???
  3. Profit

Quick and dirty pack

You can simply zip up the files needed for your package, and tell your users to unpack them in the KDE installation root.

Advantages

  • Should be real easy for you create.

Disadvantages

  • You'll have to make sure your users understand the fine points, e.g. using the correct type of KDE installation, installing in the correct directory, etc.

Procedure

  • Use
[mingw32-]make install DESTIR=Some\temporary\folder
  • Zip up Some\temporary\folder (should contain at least a "bin"-subdirectory).


Distributing as binary including KDE

Installation bundle

KDE on windows is self-contained, i.e. does not rely on the registry, or installed components outside of the main installation directory. This means you can simply zip a KDE installation (including your app) and let the user download and unzip on their system.

Advantages

  • Easy to package
  • Easy to install in a single step
  • Can use a specific setup, including specific version of KDE, specific compiler, customized default settings, etc.

Disadvantages

  • Need to offer/distribute sources!
  • Wastes download size, and disk storage, if user want more than just one KDE application.
  • No easy way to update / extend KDE installation.

Procedure

Warning

This section needs improvements: Please help us to

cleanup confusing sections and fix sections which contain a todo


Properly list the steps from that mail, and the comments from the thread in this section.

See http://lists.kde.org/?l=kde-windows&m=127499109727979&w=2 .


Custom binary installers

Custom (NSIS) installer

Of course developers can create a fully custom installer for their app, e.g. based on NSIS.

Advantages

  • Can potentially cover all situations, if sufficiently refined

Disadvantages

  • Considerable effort to create and maintain the installer

Procedure

  • Your installer should write its own kde.conf file on installation, to separate your (KDE) settings from other possible installations on that system
  • There is a NSIS package base in emerge that can be used to generate a NSIS package directly from emerge. For examples on NSIS packaging check the emerge/portage/package files.
  • For documentation on NSIS, see http://nsis.sourceforge.net .
  • One NSIS template is discussed at http://lists.kde.org/?l=kde-windows&m=127569323809833&w=2 .

Further info