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.
- 1 Setting up emerge
- 2 Using emerge
- 3 Shortcut to emerge: Precompiled snapshots
- 4 Troubleshooting and special setups
- 5 Technical background
- 6 Philosophy
Setting up emerge
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.
The emerge tool is written in Python, so you first need to install the Python 3.5 Interpreter. The python installation directory will be added to the PATH later by KDEROOT\etc\kdesettings.ini. Some packages also need Python 2.7.
Getting the emerge tool
Get the emerge tool via git with the following commands:
- if you will only use anonymous (read-only) access to the KDE git repository:
git clone git://anongit.kde.org/emerge.git
- if the git and ssh ports are blocked, and only http is allowed, it is better to clone over the http port for getting (read-only) access to the KDE git repository:
git clone http://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
- Create the directory KDEROOT\etc.
- Copy the file KDEROOT\emerge\kdesettings.ini as KDEROOT\etc\kdesettings.ini and change its contents according to your needs.
It is a good idea to read through all comments in that file, carefully. What you will definitely have to configure, is the path to Python.
Setting up a compiler
Currently emerge supports both the MinGW and MS Visual C++ (msvc) compilers:
The MinGW compiler can simply be installed via emerge (and emerge will do so, automatically as soon as it is needed). All you have to do is set the KDECOMPILER variable in KDEROOT\etc\kdesettings.ini. In fact, at the time of this writing, using MinGW is the default option.
MS Visual C++
At the time of this writing (early 2016, Qt 5.5.1), if you want to compile all of Qt, including QtWebEngine, your only choice of compiler will be Visual Studio 2013, not earlier, not later. The express version will be good enough for this purpose. In your kdesettings.ini, set KDECompiler as appropriate.
Direct X SDK
In order to compile the Qt5 qtbase package with MinGW, you will also need to install the Microsoft DirectX SDK, and set the environment variable DXSDK_DIR environment variable accordingly.
Alternatively, you can disable the use of DirectX in qt, by adding -opengl desktop to the configure parameters in Qt. (TODO: How exactly?). However, this means your Qt binaries will require an OpenGL 2.1 capable graphics card.
To use emerge you need to start a Powershell window, point that to KDEROOT\emerge and run the initalization script. For example:
C: cd KDEROOT\emerge ". .\kdeenv.ps1"
Alternatively, you can also run the kdeenv.bat script in the same directory in a traditional Windows command prompt.
This tells emerge about your environment settings (e.g. paths). It will load your configuration from KDEROOT\etc\kdesettings.ini. 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):
PS C:\kderoot\emerge>.\kdeenv.ps1 KDEROOT : r:\ KDECOMPILER : mingw-w64 KDESVNDIR : s:\ KDEGITDIR : q:\ DOWNLOADDIR : t:\ PYTHONPATH : C:\python34 PS C:\kderoot\emerge>
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 pathlength of more then around 5 characters. This problem is due to limitations of the command line length and the Qt build system.
Next, if you have configured your kdesettings.ini 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.
Installing the base system
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 frameworks. This will checkout, compile and install the kde frameworks 5 modules.
You will now have successfully installed a base KDE system and can now install other KDE modules as required.
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.
Common emerge commands
- Installing a package and its dependencies: Simply run
- Updating an installed package: Once you have packagename built, type to update packagename from git/svn and compile it without removing the build dir or
emerge --update packagenameto update all packages that can be rebuild (they are rebuild with --update).
- Continuing build after a failure: If a build failed for some reason, after fixing the issue, you often do not want to wipe the build-directory, but continue at the point of failure. Use for that.
emerge --noclean packagename
emerge command line options and settings
Below are some command-line options commonly used with emerge. A complete list of options is available by running emerge --help.
|Command line switch||Command line argument||Description|
|--help||Print usage information.|
|--print-installable||List packages available for installation.|
|--print-installed||List installed packages.|
|-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.ini 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.|
Building a specific version of KDE
The instructions as given above will install the development version of KDE (master in most 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.
emerge has several branches which contain specific package versions. E.g. if you want to build the 4.13 branch of KDE (or one of the 4.13 releases) you should checkout the kde-4.13 branch of emerge; in the master branch, you can find the KDE Frameworks 5. TODO: Any mechanism for switching between KF5 releases?
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.13
At the moment, only the master branch is actively maintained, so you will likely experience problems (outdated package urls etc.) on the other branches. If you really, really need to work with a historic version of KDE, and you cannot get it to work using emerge, one alternative may be to set up a compilation environment using the KDE on Windows installer. There also exists a snapshot of a 32bit MinGW based emerge installation of KDE 4.10: https://sourceforge.net/projects/rkwardextras/files/Archive/Windows/Development/ .
Even more historic instructions:
Shortcut to emerge: Precompiled snapshots
If you do not have any special requirements over than setting up a KF5 environment on Windows for testing, reliably and quickly, you may be interested in some pre-built snapshots. Note that it is still a good idea to have at least a basic understanding of the steps outlined, above, including the setup requirements.
Troubleshooting and special setups
- 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.
Windows 10 specifics
- To allow scripts such as kdeenv.ps1 to run, you may need to set execution policy for scripts to unrestricted. Of course, this means you should know what you're doing when you run scripts etc. The way to do this is to first get a powershell as administrator:
PS> Start-Process powershell -Verb runAs
Then, once you get an administrative powershell, run:
This should let scripts run
- To allow .exe files that are downloaded by emerge to run, you need to have permissions. Otherwise, emerge will give you an "Access denied" error and quit. The details of which program failed can be found by running emerge --verbose <packagename>.
There's got to be a better, global way to fix this issue just like in the above case, but a work-around is to go to the containing folder in Windows Explorer, Right click on the .exe file, click properties, go to the permissions tab, say "edit" permissions, and set it to Read & Execute "Allow" for everyone.
The author of this blurb had to do this for the following programs: wget (wget.exe) 7zip (7za.exe)
Building for 32 bit on a 64 bit machine
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 by adding a file emerge-boost-config.jam in the %KDEROOT%\etc directory to build boost in a specific way, with the following contents:
# --------------------- # Python configuration. # --------------------- # Configure specific Python version. using python : 3.2 : C:\\Python32_x86 ;
This way boost-python would be using the headers & libraries from C:\\Python32_x86 instead of the default one. Please remember that for mingw compilers you must regenerate the import library for the python dll (also for the mingw 64bit compiler):
R:\> emerge pexports R:\> pexports C:\Python32_x86\python32.dll > C:\Python32_x86\libs\python32.def
NOTE: In case you generate the import library for the 64bit compiler, add the following line to the file python32.def:
Py_InitModule4 = Py_InitModule4_64
For both compilers you should now run:
dlltool -d C:\Python32_x86\libs\python32.def -l C:\Python32_x86\libs\libpython32.dll.a
Now you should be able to do emerge -i boost-python-src without errors.
What emerge does
Emerge can be thought of as performing many of the functions of automated tools like cmake, but in a flexible Python scripting framework. The benefit of this is that new libraries with idiosyncratic installation procedures, conflicting library and header installation names, and complex rules for building on different setups can be generated automatically, and all directory management should be taken care of without the user's input.
The primary logic for the program is contained in the /bin folder of the Git repository. The script emerge.py serves as the entry point to the system; it runs appropriate code according to the command line arguments. The basic command emerge packageName performs the five most important actions --fetch, --unpack, --compile, --install, and --qmerge. The definition for each of these steps is defined using a flexible system called Portage, after the Gentoo package management system. The basic goals are:
1. Fetch action retrieves either a binary or the source code for the package.
2. Unpack action installs the source code in a source folder and applies KDE-specific patches.
3. Compile action runs package-dependent configure make steps.
4. Install action installs the headers and compiled library and executable outputs.
5. Qmerge action does something, but what?
Emerge also offers functionality to document dependency trees, create patches to upload tweaks and fixes, and update and clean existing installs.
The actual commands for fetching, unpacking etc. are defined by three increasingly specialized levels of logic. The first level is the code in the /bin folder and determines the overall order, steps should be taken, reading environment variables to configure the build environment and compiler set by kdeenv.bat, and parsing the directory tree.
The second set of logic is found in the /bin/BuildSystem, /bin/Package, /bin/Packager, and /bin/Source folders. This is used to determine general procedures for different classes of packages. For example, the "Source" folder contains the logic for running the --fetch step for compressed files, git repositories, SVN, and so on. The "Package" system contains logic for libraries that need to be configured with e.g. CMake, QMake, or internal make systems.
The final set of logic is at the per-package level. This is what is contained in the /portage/ directory. Emerge is able to automatically search through the Portage folders to find the name of the package you specify. This is where dependencies, special build configurations and special commands are set up. Individual patch files and different version configuration information is also stored here. It is relatively straightforward to add a new package to Portage, especially if the package itself can be downloaded and installed with CMake using minimal configuration.
A good way to prepare a package for wider distribution is to create a simple CMakeLists.txt it. You can format the addition of this file as a patch, and create a Portage script which merges the patch into the public code repository.
Fixing problems and sharing your work
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:
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 Git 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.
Easy for us to do build
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.
Easy 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.