1. grimmdp
  2. WinMerge


Clone wiki

WinMerge / Developing


One challenge is to switch to totally freely available tools. This is very important for people to be able to compile WinMerge and to contribute to WinMerge.

WinMerge 2.x uses MFC library heavily. MFC is not free but it comes with commercial editions of Visual Studio. So you can't compile WinMerge with Cygwin, MinGW, Visual Studio Express edition or other free compilers. You have to buy expensive compiler first.

WinMerge 3.x must be compilable with GCC and free Visual Studio express edition. Also Qt creator should be possible to use.

Supported development environments

  • Visual Studio 2008 or later (including Express editions)
    • Qt 4.7.x is required for VS2010 qmake support
  • Qt creator
  • GCC

Build system

Qt's Qmake will be used as build system. We write project files as Qmake project files. Then Qmake can generate project files for different platforms/environments. This is much easier and less work than trying to maintain make/project files for several platforms/environments.

Creating make/project files with qmake

  • In Linux you can simply type: qmake
  • In Windows type:
    • qmake -- to create NMake makefiles
    • qmake -tp vc -- to create VS project/solution files. You may need to also define the spec for the compiler/enviroment you are using with -spec param (qmake -tp vc -spec win32-msvc2010 for VS 2010)

Line endings

We will use Linux EOL style in:

  • C/C++ code files
  • UI files (generated by Qt Creator)
  • PRO files
  • text files
  • scripts

It is the only sane choice for cross-platform software. However strictly Windows-specific files can use (and sometimes are required to use to work) DOS EOL style. For example BAT files can have DOS EOL style. Latest Astyle versions make sure C++ files have correct EOL style.


Use all lowercase letter filenames in general. That is the easiest and most portable way. There are some exceptions like COPYING and AUTHORS which have been traditionally written with capitals and lots of people expect to find those files.

Coding style

We will use Astyle to format the code. Everybody is supposed to run astyle for the code before committing.

marcelgosselin : Since we are starting from scratch, should we define other coding guidelines like:

  • One class per file
  • Capitalization (ClassName, parameterName, MACRO_OR_CONSTANT, MethodName, etc...)
  • Use shared pointers (aka boost::shared_ptr/std::tr1::shared_ptr/our own) for all dynamically allocated memory, except for Qt's classes
  • Always put enum definitions inside a class or namespace to provide a scope for the enum constants
  • ...

kimmov : agreed, we definitely should have better coding guidelines defined so that code isn't in ten different styles like it is in WinMerge 2.x.


Use small commits rather than big commits. Unlike with SVN you can create tens of commits locally and then integrate them to all with one push to central repository. Commits are very cheap so use them!

Commit message format

Every commit message should have short one line description at first line and more verbose (if needed) description below it. There should be empty line between short description line and more verbose description.

Please format your commit messages as follows:

topic: terse one-line summary (60 characters max)

After the summary line, you're encouraged to provide a bigger
description of your changes. If your change is small or obvious
from the diff, you can leave this out.

Please wrap your paragraphs at ~70 characters or so. That ensures
that they are readily readable on a standard terminal.

Motivation here is that all log data is always usable. But data in remote bug/task trackers might not be. It is also easier and faster when the explanation for the change is in log and people don't need to go to another system to get it.


Mercurial supports flexible branching and using branches during development is encouraged. However there are couple of rules:

  • use of Mercurial named branches is only allowed for long-time branches like release branches. Do not use them for feature development or experimentation (or at least don't push those branches to BB repository).
  • Use bookmarks, anonymous branches or patch queues for short-lived development like developing new features.

Read the branching guide.


We use Qt Creator and its generated .ui files for creating windows and dialogs. If you want to edit existing dialog/window, open the UI file to Qt Creator and modify it. If you want to create new window/dialog then create new UI file with Qt Creator. Then you need to create the C++ code to show and use the UI file. You can use existing dialogs as an example for how to use UI files GUI from the code.

NOTE: In Windows Qt Creator always saves UI files with DOS EOLs. You MUST convert the file EOLs to Linux style before committing the file!