Projects/KDE on Windows/Development Workflow: Difference between revisions

From KDE TechBase
(Start working on a workflow page for KDE on Windows. More to come.)
 
No edit summary
Line 18: Line 18:
== Where are the emerge build files ==
== Where are the emerge build files ==


Often some builds will fail for trivial reasons, like a download failing because the file has moved. This type of error (but also missing or wrong configuration options, and many others) can be corrected in the emerge build files. These are in (subdirectories of) ''emerge/portage/''. Each package has its own subdirectory. In each subdirectory you will find at least one .py-file. I am not aware of any in-depth information on the semantics of these files, but most concepts should be fairly obvious, and if you are unsure, look at other build files for examples.


== Where are the sources ==
== Where are the sources ==


* git / svn / others
If the problem needs fixing somewhere inside the source tree, you may be wondering where to look for the sources.
 
* git-based sources are in subdirectories of ''%KDEROOT%''/git
* svn-based sources are in subdirectories of ''%KDEROOT%''/svn
* archived sources are first downloaded to ''%KDEROOT%''/download. Then, the archives get unpacked to ''%KDEROOT%''/build/''category''/''packagename''/work/ .


== Debugging and testing ==
== Debugging and testing ==
When developing a fix on the level of a package's source code, first locate the final source tree, as detailed above. You do your work directly in the source tree. For quick testing, you can cd to the build directory (''%KDEROOT%''/build/''category''/''packagename''/work/''compiler_buildtype-version''). Assuming configuration is already complete you can often build directly from there (for MinGW4 use ''mingw32-make'').


* build directory
* build directory

Revision as of 17:01, 10 December 2012

Development Workflow for KDE on Windows

Under Contruction!

Basics

Before we start: This page will not tell you how to diagnose and address problems or shortcomings in source code and build files. We assume you know all that already, or are willing to read up on any missing bits, on your own (but for some hints on useful tools and techniques, be sure to visit Development/Tutorials/Debugging/Debugging on MS Windows, and Projects/KDE on Windows/Tools. The pupose of this page is to give you an outline of the specific steps needed for preparing, testing, and publishing patches in the KDE on Windows project.

Use emerge

You are using emerge to build your KDE on Windows development environment, right? If not, start doing so now. It's mandatory. Some variables to check in your emerge setup:

  • EMERGE_BUILDTYPE: You may want to set this to "Debug"
  • EMERGE_LOG_DIR: Setting this is highly useful, so you can review (long) build logs.
  • GIT_AUTHOR_*/GIT_COMMITTER_*: Useful if you want to be able to make commits directly from your source tree.
  • Be sure you are on the branch you want to be on!

Where are the emerge build files

Often some builds will fail for trivial reasons, like a download failing because the file has moved. This type of error (but also missing or wrong configuration options, and many others) can be corrected in the emerge build files. These are in (subdirectories of) emerge/portage/. Each package has its own subdirectory. In each subdirectory you will find at least one .py-file. I am not aware of any in-depth information on the semantics of these files, but most concepts should be fairly obvious, and if you are unsure, look at other build files for examples.

Where are the sources

If the problem needs fixing somewhere inside the source tree, you may be wondering where to look for the sources.

  • git-based sources are in subdirectories of %KDEROOT%/git
  • svn-based sources are in subdirectories of %KDEROOT%/svn
  • archived sources are first downloaded to %KDEROOT%/download. Then, the archives get unpacked to %KDEROOT%/build/category/packagename/work/ .

Debugging and testing

When developing a fix on the level of a package's source code, first locate the final source tree, as detailed above. You do your work directly in the source tree. For quick testing, you can cd to the build directory (%KDEROOT%/build/category/packagename/work/compiler_buildtype-version). Assuming configuration is already complete you can often build directly from there (for MinGW4 use mingw32-make).

  • build directory
  • mingw32-make
  • emerge -i
  • emerge --update
  • diffutils

Creating patches

  • emerge --createpatch
  • Adding to build_xyz.py
  • Renaming build_xyz.py?
  • Don't forget to test from a clean workdir.

Review and Pushing

  • reviewboard, mailing list, IRC
  • git commands (short)
  • merging to / from master