Jump to content

Guidelines and HOWTOs/Build from source/Windows

From KDE Community Wiki

emerge is a tool to build the KDE sources and its third-party requirements on MS Windows. It is the easy way to build KDE on MS Windows.

Introduction

Emerge is a tool that can build the different parts of KDE and its dependencies under Windows. We created this tool to automate and simplify the build process under Windows. We try to build all packages that we offer in the KDE installer with emerge. That has some advantages for us:

  • it is easy for people to join us:

Before emerge it was quite some work to set a system up for development. There were some quirks, which were documented in some mailing lists, but you had to remember them or you ran into an already solved problem again, etc. Now to get a development machine you need a Windows computer, need to install Python and Subversion and do the emerge checkout. Then execute emerge to build what you want to build. This is easy for developers coming from Windows to KDE, and also for KDE developers coming to Windows.

  • it is easy for us to do (nightly/continuous/release/reproducable/...) builds:

With emerge you can build the whole software stack (low-level libs, Qt, kdelibs, things above that) with only one command. You can start that build, and some hours later you can check if it worked, or if something broke. So we can spot problems easier and earlier. We can also start with a "naked" Windows computer without any other installed software and bootstrap kde on it. That ensures, that no hidden dependencies on some pieces of software sneak in, because then the builds on a "naked" computer would break and show the problem.

  • it is easier to collaborate:

We can test the same emerge build description for a package on different Windows versions/computers before we do binary releases. People can also add build descriptions for new packages to the Subversion repository.

This emerge tool was inspired by the Gentoo emerge tool.

Set up the environment

Root directory

Create a directory if possible in your harddrive's root e.g. C:\kderoot or D:\kderoot (You will need this PATH later). This directory will contain the whole kde installation later. We will refer to it as %KDEROOT%.

Python interpreter

emerge.bat invokes an emerge.py script written in Python programming language, so you first need to install the Python 2.7 Interpreter. The python installation directory will be added to the PATH later by %KDEROOT%\etc\kdesettings.bat script.

Git client

The latest source code for Windows emerge and a lot of the rest of KDE is stored in a repository created and managed using the Git version control tool. You need a git client for the first checkout of emerge. There are at least two applications:

  • a command line client, available at subversion.apache.org, aimed at developers or power users accustomed with the command line,
  • a GUI program like TortoiseGit, optional, useful for displaying differences between various versions of files in the repository in a graphical way.

Emerge uses its own git client for checking out all KDE source code. You can find it in %KDEROOT%\dev-utils\git\bin. It will be used by emerge even if you have another git executable installed.

Getting the emerge tool

The source code of the emerge tool and the recipes for creating KDE packages are located at git://anongit.kde.org/emerge.git, which is an URL based on the git-specific git protocol.

You need to check out the source code from the emerge Subversion directory into a new directory below your root directory (the root directory is normally called %KDEROOT% here) or get it inside a self extracting archive (not tested yet).

Check out using the 'git' command

  • Option 1: With the git command line tool, you can accomplish this with the following commands:
    cd %KDEROOT%
    • if you will only use anonymous (read-only) access to the KDE git repository:
      git clone git://anongit.kde.org/emerge.git
    • or, if you plan to use write access (commit) to the emerge repository using your existing account & OpenSSH private key:
      git clone [email protected]:emerge.git

Configure the emerge tool

  1. Create the directory %KDEROOT%\etc.
  2. Copy the file %KDEROOT%\emerge\kdesettings-example.bat as %KDEROOT%\etc\kdesettings.bat and change its contents according to your needs. The options are described in the rem lines in the file itself.

The kdesettings.bat script will be called by the main kdeenv.bat script.

Note 1: Be sure that you neither have the msys/bin nor the cygwin/bin in your path. If so you have to definitely remove it from the path.

Note 2 from a user: The applications gimp, inkscape and graphviz are also a problem. To make sure that there's nothing wrong I stripped my path to contain only what I needed to build.

Note 3 from another user: be careful when renaming the file to "kdesettings.bat" it is easy to end up with "kdesettings.bat.bat" instead of what you want since Windows(by default) will not show the the file extension part of a file.

emerge has several branches which contain specific package versions. E.g. if you want to build the 4.7 branch of KDE (or one of the 4.7 releases) you should checkout the kde-4.7 branch of emerge; in the master branch, you can find KDE master/trunk. To view all branches, use the following command:

git branch -a

To change the branch of emerge, do the following:

cd emerge && git checkout kde-4.7

[Optional, Advanced] emergehosts.conf

Add a file emergehosts.conf in the %KDEROOT%\etc directory. The format of this file is a typical config file with only two entries per section: The first entry is the host as mentioned in the portage file for the package. The second entry is called replace and is the replace string for the host string.

As an example, here is how to checkout all gitorious based repos of the kde-developers group using a push url instead of the anonymous access:

[qt gitorious]
host: git://gitorious.org/+kde-developers/
replace: [email protected]:+kde-developers/

As a second example here is how to checkout with a ssh user from a subversion repository:

[svn.example.com]
host: svn://svn.example.com/
replace: svn+ssh://[email protected]/

The name of the section doesn't matter and can be used for descriptions.

[Optional, Advanced] emerge-boost-config.jam

Add a file emerge-boost-config.jam in the %KDEROOT%\etc directory to build boost in a specific way. The only current use case is for the following problem: If you build 32bit binaries with emerge on a 64bit system you need to link boost-python against a 32bit python library. In case your standard python installation is 64bit though, you can specify the python installation in the following way:

# ---------------------
# Python configuration.
# ---------------------

# Configure specific Python version.
using python : 2.7 : C:\\Python27_x86 ;

Using emerge

To use emerge you need to start a console window and point that to %KDEROOT%\emerge. For example:

C:
cd \%KDEROOT%\emerge

Then you have to execute

kdeenv.bat

This tells emerge about your environment settings (e.g. paths). It will load your configuration from %KDEROOT%\etc\kdesettings.bat. It should not give any error messages, otherwise emerge will not work as expected. The output should look similar to this one (of course with your paths):

C:\kderoot\emerge>kdeenv.bat
kdesettings.bat executed
KDEROOT     : C:\kderoot
KDECOMPILER : mingw
KDESVNDIR   : C:\kderoot\svn
PYTHONPATH  : C:\python27
DOWNLOADDIR : C:\kderoot\download
C:\kderoot\emerge>

Next, if you have configured your kdesettings.bat to use svn+ssh for your subversion checkout, then you need to run:

plink <your-svn-username>@svn.kde.org
plink <your-kde-username>@git.kde.org

This will prompt you to accept the fingerprint of the server, otherwise svn will hang forever when trying to download from the server.

Now you should be able to use emerge. Type

emerge --help

to get some help on usage.

Note: There is a short path option in kdesettings which you will need if you want to build Qt in a directory that has a pathlenght of more then around 5 characters. This problem is due to limitations of the command line length and the Qt build system.

Setting up a compiler

Currently emerge supports both the MinGW and MS Visual C++ (msvc) compilers. We did not add dependencies for the compilers, so you have to make sure to install a compiler by yourself. There are three ways to set up a compiler for emerge. We assumed you have set KDECOMPILER variable properly in the %KDEROOT%\etc\kdesettings.bat.

In the following sections you can find information on how to install or reuse an existing compiler.

Install the MinGW compiler with emerge

Let emerge install the MinGW compiler, as soon as emerge needs MinGW it will automatically fetch the correct version for you.

Install MS Visual C++

Read here.


Point to an existing MS Visual C++ installation

You need to point emerge to an existing msvc installation. This is run automatically for you from kdeenv.bat if configured properly in kdesettings.bat. Check your kdesettings.bat file to know where to set it.

Installing the base system

Once you have emerge and a compiler installed and working, try:

  • emerge --help for a list of available commands
  • emerge --print-installable to get a list of available packages
  • emerge --print-installed to get a list of currently installed packages

Further options are described below.

You are now ready to start building KDE, it is recommended to do so progressively, relying on emerge to automatically resolve the required dependencies at each set step:

  • Enter emerge qt. This will fetch and install Windows versions of numerous UNIX-like utilities and libraries, then checkout, compile and install Qt. This will take several hours.
  • Enter emerge kdelibs. This will checkout, compile and install the required kdesupport modules and then kdelibs.
  • Enter emerge kde-baseapps. This will checkout, compile and install kdebase-runtime, and kdebase-apps.

You will now have successfully installed a base KDE system and can now install other KDE modules as required.

Note that this will install the development version of KDE (trunk in svn repositories, master in git repositories), if you wish to install a particular stable branch then you should change the branch of emerge to the specific branch of that release. NOTE: You should not mix kde packages from different branches.

It is strongly recommended you do not choose to manually install any of the utilities and libraries yourself, as you may install the wrong version and cause installation failures. Instead allow emerge to resolve the dependencies for you.

Every time you want to update or install a package, you should first update your emerge checkout (simply run emerge --update emerge) to ensure you are using the latest package recipies.

What emerge does

emerge packageName performs the separate actions --fetch, --unpack, --compile, --install, and --qmerge.

The --fetch action will retrieve either a binary or the source code for the package:

  • If a binary package, this will be downloaded into the DOWNLOADDIR defined in your kdesettings.bat, which is usually %KDEROOT%\download.
  • If a non-KDE source package, the source repository will be checked-out into %DOWNLOADDIR%\svn-src, e.g. Qt source may be found in C:\kderoot\download\svn-src\qt.
  • If a KDE source package from the svn.kde.org repository, then the source will be checked-out into the KDESVNDIR defined in your kdesettings.bat, which is usually %KDEROOT%\svn.

emerge command line options and settings

There are some options that can be used when building with emerge.

Command line switch Command line argument Description
-v EMERGE_VERBOSE This option sets the verbosity level. Currently the highest verbosity level is 3 (-v -v -v). A verbosity level of 0 should give no output and equals to -q. You can set EMERGE_VERBOSE=3 instead in the environment of the commandline or within your kdesettings.bat file.
--offline This option suppresses the update step of the local tree - which needs some time. Be aware though that you have to have existing sources already if you want to use this option.
-t EMERGE_BUILDTESTS This option enables or disables KDE4 buildtests for KDE modules. Other packages will not change. Use EMERGE_BUILDTESTS=True or =False.
--print-targets This option will display all "targets" a certain package has. Normally targets are fixed releases or different branches. They are defined in the portage file.
--target=TARGET This sets a specific target for this package. If not added, the default target is used, which can be checked by looking at the output of --print-targets.
-i This option ignores that a package is already installed. It builds it completely new, but keeps the dependencies.
--update This option ignores that a package is already installed but doesn't cleanup an already existing build directory. Thus you will only rebuild files that have changed since the last build.

Hints

Updating packages

  • Once you have packagename built, type
    emerge --update packagename
    
    to update packagename from the Subversion and compile it without removing the build dir or
    emerge --update-all
    
    to update all packages that can be rebuild (they are rebuild with --update).

General setup

For Fine Tuning see here: Fine-tuning

Notes

emerge can mostly cooperate with the kdewin-installer but we're currently still working on some packages which are packaged in a wrong way. It is not recommended to use another layout then installer for directory_layout in the kdesettings.bat anymore (see that file for more detailed information).

emerge creates lots of files in \kderoot\tmp during build. After a package is successfully installed (check \kderoot\etc\portage\installed or the directory \kderoot\manifest\), you can delete its temporary directory.

Windows emerge is derived from the Gentoo portage system, but we are currently not enforcing compatibility. If you have questions about that please contact us at the channel #kde-windows on irc.freenode.net.

last reviewed by SaroEngels 22:52, 26th July 2011 (UTC)

Vista issues

  • jstaniek 12:02, 15 January 2008 (CET): UAC has infamous heuristics that make programs like patch.exe treat as installers and try to run them with admin rights (!). This heuristics can be tricked by renaming patch.exe to something like pch.exe (example) but we did not want to add item to our infrastructure. Instead it is possibleto turn off the heuristics (see the screenshot here in the security blog calling the heuristics 'severe hole in the design of UAC'). If you happen to disable the UAC, as many annoyed users and devs do (msvc demands admin rights anyway!), patch.exe should already work for you as in older Windows. Alternatively you may want to disable UAC for admins only, but this makes no sense if you are the only user of your machine and use only the admin account.
  • This wiki page lists instructions on how to use program manifest to disable privilege elevation for a single binary and makes patch play nice with UAC. This should eventually be integrated to emerge scripts.