208 lines
5.8 KiB
XML
208 lines
5.8 KiB
XML
<?xml version='1.0' encoding="utf-8"?>
|
|
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
"docbook/dtd/xml/4.2/docbookx.dtd">
|
|
<book>
|
|
<title>The Music Player Daemon - Developer's Manual</title>
|
|
|
|
<chapter>
|
|
<title>Introduction</title>
|
|
|
|
<para>
|
|
This is a guide for those who wish to hack on the MPD source
|
|
code. MPD is an open project, and we are always happy about
|
|
contributions. So far, more than 150 people have contributed
|
|
patches.
|
|
</para>
|
|
|
|
<para>
|
|
This document is work in progress. Most of it may be incomplete
|
|
yet. Please help!
|
|
</para>
|
|
</chapter>
|
|
|
|
<chapter>
|
|
<title>Code Style</title>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
indent with tabs (width 8)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
don't write CPP when you can write C++: use inline
|
|
functions and constexpr instead of macros
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
the code should be C++11 compliant, and must compile with
|
|
<application>GCC</application> 4.6 and
|
|
<application>clang</application> 3.2
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Some example code:
|
|
</para>
|
|
|
|
<programlisting lang="C">static inline int
|
|
foo(const char *abc, int xyz)
|
|
{
|
|
if (abc == NULL) {
|
|
LogWarning("Foo happened!");
|
|
return -1;
|
|
}
|
|
|
|
return xyz;
|
|
}
|
|
</programlisting>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</chapter>
|
|
|
|
<chapter>
|
|
<title>Hacking The Source</title>
|
|
|
|
<para>
|
|
MPD sources are managed in a git repository on <ulink
|
|
url="http://git.musicpd.org/">git.musicpd.org</ulink>.
|
|
</para>
|
|
|
|
<para>
|
|
Always write your code against the latest git:
|
|
</para>
|
|
|
|
<programlisting>git clone git://git.musicpd.org/master/mpd.git</programlisting>
|
|
|
|
<para>
|
|
If you already have a clone, update it:
|
|
</para>
|
|
|
|
<programlisting>git pull --rebase git://git.musicpd.org/master/mpd.git master</programlisting>
|
|
|
|
<para>
|
|
You can do without "--rebase", but we recommend that you rebase
|
|
your repository on the "master" repository all the time.
|
|
</para>
|
|
|
|
<para>
|
|
Configure with the options <option>--enable-debug
|
|
--enable-werror</option>. Enable as many plugins as possible,
|
|
to be sure that you don't break any disabled code.
|
|
</para>
|
|
|
|
<para>
|
|
Don't mix several changes in one single patch. Create a
|
|
separate patch for every change. Tools like
|
|
<application>stgit</application> help you with that. This way,
|
|
we can review your patches more easily, and we can pick the
|
|
patches we like most first.
|
|
</para>
|
|
|
|
|
|
<section>
|
|
<title> Basic stgit usage</title>
|
|
|
|
<para>
|
|
stgit allows you to create a set of patches and refine all of
|
|
them: you can go back to any patch at any time, and re-edit it
|
|
(both the code and the commit message). You can reorder
|
|
patches and insert new patches at any position. It encourages
|
|
creating separate patches for tiny changes.
|
|
</para>
|
|
|
|
<para>
|
|
stgit needs to be initialized on a git repository: stg init
|
|
</para>
|
|
|
|
<para>
|
|
Before you edit the code, create a patch: stg new
|
|
my-patch-name (stgit now asks you for the commit message).
|
|
</para>
|
|
|
|
<para>
|
|
Now edit the code. Once you're finished, you have to "refresh"
|
|
the patch, i.e. your edits are incorporated into the patch you
|
|
have created: stg refresh
|
|
</para>
|
|
|
|
<para>
|
|
You may now continue editing the same patch, and refresh it as
|
|
often as you like. Create more patches, edit and refresh them.
|
|
</para>
|
|
|
|
<para>
|
|
To view the list of patches, type stg series. To go back to a
|
|
specific patch, type stg goto my-patch-name; now you can
|
|
re-edit it (don't forget stg refresh when you're finished with
|
|
that patch).
|
|
</para>
|
|
|
|
<para>
|
|
When the whole patch series is finished, convert stgit patches
|
|
to git commits: stg commit
|
|
</para>
|
|
</section>
|
|
</chapter>
|
|
|
|
<chapter>
|
|
<title>Submitting Patches</title>
|
|
|
|
<para>
|
|
Send your patches to the mailing list:
|
|
<email>mpd-devel@musicpd.org</email> (<ulink
|
|
url="http://mailman.blarg.de/listinfo/mpd-devel">subscribe
|
|
here</ulink>)
|
|
</para>
|
|
|
|
<para>
|
|
<command>git pull</command> requests are preferred. Regular
|
|
contributors can get <ulink
|
|
url="http://git.musicpd.org/account-policy.html">an account on
|
|
git.musicpd.org</ulink>, but any public git repository will do.
|
|
</para>
|
|
</chapter>
|
|
|
|
<chapter>
|
|
<title>Development Tools</title>
|
|
|
|
<section>
|
|
<title>Clang Static Analyzer</title>
|
|
|
|
<para>
|
|
The <ulink url="http://clang-analyzer.llvm.org/">clang static
|
|
analyzer</ulink> is a tool that helps find bugs. To run it on
|
|
the MPD code base, install LLVM and clang. Configure MPD to
|
|
use clang:
|
|
</para>
|
|
|
|
<programlisting>./configure --enable-debug CXX=clang++ CC=clang ...</programlisting>
|
|
|
|
<para>
|
|
It is recommended to use <option>--enable-debug</option>,
|
|
because the analyzer takes advantage of
|
|
<function>assert()</function> calls, which are only enabled in
|
|
the debug build.
|
|
</para>
|
|
|
|
<para>
|
|
Now run the analyzer:
|
|
</para>
|
|
|
|
<programlisting>scan-build --use-c++=clang++ --use-cc=clang make</programlisting>
|
|
|
|
<para>
|
|
The options <option>--use-c++</option> and
|
|
<option>--use-cc</option> are necessary because it invokes
|
|
<command>cc</command> for actually compiling the sources by
|
|
default. That breaks, because MPD requires a C99 compiler.
|
|
</para>
|
|
</section>
|
|
</chapter>
|
|
</book>
|