doc: remove developer.xml, was converted to Sphinx
This commit is contained in:
Max Kellermann
parent
104b8b4c4c
commit
51951c9442
@ -2512,7 +2512,7 @@ endif
|
||||
man_MANS = doc/mpd.1 doc/mpd.conf.5
|
||||
doc_DATA = AUTHORS COPYING NEWS README.md doc/mpdconf.example
|
||||
|
||||
DOCBOOK_FILES = doc/protocol.xml doc/user.xml doc/developer.xml
|
||||
DOCBOOK_FILES = doc/protocol.xml doc/user.xml
|
||||
|
||||
if ENABLE_DOCUMENTATION
|
||||
protocoldir = $(docdir)/protocol
|
||||
@ -2521,9 +2521,6 @@ protocol_DATA = $(wildcard doc/protocol/*.html)
|
||||
userdir = $(docdir)/user
|
||||
user_DATA = $(wildcard doc/user/*.html)
|
||||
|
||||
developerdir = $(docdir)/developer
|
||||
developer_DATA = $(wildcard doc/developer/*.html)
|
||||
|
||||
DOCBOOK_HTML = $(patsubst %.xml,%/index.html,$(DOCBOOK_FILES))
|
||||
|
||||
DOCBOOK_INCLUDES = $(wildcard $(srcdir)/doc/include/*.xml)
|
||||
@ -2561,7 +2558,6 @@ upload: $(DOCBOOK_HTML) doc/api/html/index.html
|
||||
--chmod=Dug+rwx,Do+rx,Fug+rw,Fo+r \
|
||||
--include=protocol --include=protocol/** \
|
||||
--include=user --include=user/** \
|
||||
--include=developer --include=developer/** \
|
||||
--include=api --include=api/** \
|
||||
--exclude=*
|
||||
|
||||
|
||||
@ -1,231 +0,0 @@
|
||||
<?xml version='1.0' encoding="utf-8"?>
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
|
||||
|
||||
<book>
|
||||
<title>The Music Player Daemon - Developer's Manual</title>
|
||||
|
||||
<chapter id="introduction">
|
||||
<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 id="code_style">
|
||||
<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>
|
||||
comment your code, document your APIs
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
the code should be C++14 compliant, and must compile with
|
||||
<application>GCC</application> 6.0 and
|
||||
<application>clang</application> 3.4
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
report error conditions with C++ exceptions, preferable
|
||||
derived from <varname>std::runtime_error</varname>
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
all code must be exception-safe
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
classes and functions names use CamelCase; variables are
|
||||
lower-case with words separated by underscore
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Some example code:
|
||||
</para>
|
||||
|
||||
<programlisting lang="C">static inline int
|
||||
Foo(const char *abc, int xyz)
|
||||
{
|
||||
if (abc == nullptr) {
|
||||
LogWarning("Foo happened!");
|
||||
return -1;
|
||||
}
|
||||
|
||||
return xyz;
|
||||
}
|
||||
</programlisting>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</chapter>
|
||||
|
||||
<chapter id="hacking">
|
||||
<title>Hacking The Source</title>
|
||||
|
||||
<para>
|
||||
MPD sources are managed in a git repository on <ulink
|
||||
url="https://github.com/MusicPlayerDaemon/">GitHub</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Always write your code against the latest git:
|
||||
</para>
|
||||
|
||||
<programlisting>git clone git://github.com/MusicPlayerDaemon/MPD</programlisting>
|
||||
|
||||
<para>
|
||||
If you already have a clone, update it:
|
||||
</para>
|
||||
|
||||
<programlisting>git pull --rebase git://github.com/MusicPlayerDaemon/MPD 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 id="submitting_patches">
|
||||
<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.
|
||||
</para>
|
||||
</chapter>
|
||||
|
||||
<chapter id="tools">
|
||||
<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>
|
||||
Loading…
Reference in New Issue
Block a user