[mkgmap-dev] mkgmap build process: how to apply patches

Mon Aug 24 15:29:14 BST 2009

Hi Torsten,

> I am trying to attend the mkgmap devellopment, but I have still some
> trouble with the build process, partly because I am also not familiar
> with the Linux environment.

You don't have to use Linux. I do but other people use Windows or
Macs.

> As a start I installed Suse Linux and the Eclipse IDE.
> 
> First step was downloading the source package from the mkgmap download
> page, extracting this package into a folder, creating an ANT-project in
> Eclipse and finally building mkgmap. Ok, this worked.
> 
> Second step was using kdesvn and retrieving the sources from svn-trunk
> via subversion instead of downloading the source package. On this
> working copy I was again able to build mkgmap via an ANT-Eclipse-Project.
> 
> But I haven't figured out yet, how to integrate a patch provided via
> this list into my build process. Can anybody give me some advise, how to
> use the patches?

Patches can be applied using the "patch utility". The trick with
patches is making the filenames that are in the patch, match the files
in the current working directory (and below).

In the simplest case, you can say (on the Linux command line)

patch < patchfile.

But often, it will complain that it can't find the patch and then you
have to either change into a lower subdirectory, and/or use the -p
option to patch to tell it to strip prefix directories from the patch
filenames. E.g.

patch -p1 < patchfile.

I always make a new branch before I apply a patch someone has posted
because then if it all goes wrong it doesn't affect my master branch
or any of my development branches. If the patch is good, I can always
merge it into other branches later. I don't use svn but git which makes
all this branching/merging stuff stress free. E.g.

git branch test-branch   (make a new branch based on current branch)
git checkout test-branch (check out new branch)
patch -p1 < some-patch   (apply the patch)
test/edit/commit/etc.   (frig around with patch till satisfied it's good)
git checkout master      (go back to master branch)
git merge test-branch    (merge in the test branch to master)

I don't know about svn but git makes it very easy to have any number of
branches which you can switch between in an instant and merge together.
Also it's (generally) trivial to maintain development branches that
can be "rebased" on top of the latest master branch so that as the
master gets updated with new commits, you can update your development
branches to incorporated those commits without losing the branch
structure. And, of course, you have the full development history
available all the time. I digress.

Cheers,

Mark