mirror of
https://github.com/djcb/mu.git
synced 2024-06-30 08:01:07 +02:00
131 lines
4.0 KiB
Plaintext
131 lines
4.0 KiB
Plaintext
* HACKING
|
|
|
|
Here are some guidelines for hacking on the 'mu' source code.
|
|
|
|
This is a fairly long list -- this is not meant to discourage anyone from
|
|
working on mu; I think most of the rules are common sense anyway, and some of
|
|
the more stylistic-aesthetic rules are clearly visible in current source code,
|
|
so as long as any new code 'fits in', it should go a long way in satisfying
|
|
them.
|
|
|
|
I should add some notes for the Lisp/Scheme code as well...
|
|
|
|
** Coding style
|
|
|
|
For consistency and, more important, to keep things understandable, mu
|
|
attempts to follow the following rules:
|
|
|
|
1. Basic code layout is like in the Linux kernel coding style. Keep the '{'
|
|
on the same line as the statement, except for functions. We're slowly
|
|
moving to use SPC for indentation: all new code should use that.
|
|
|
|
While TABs are techically better, it seems that using SPCs is harder to
|
|
get wrong.
|
|
|
|
2. Lines should not exceed 100 characters
|
|
|
|
3. Functions should be kept short.
|
|
|
|
4. Source files should not exceed 1000 lines, with few exceptions.
|
|
|
|
5. Non-static C-functions have the prefix based on their module, e.g.,
|
|
~mu-foo.h~ declares a function of 'mu_foo_bar (int a);', mu-foo.c implements
|
|
this. C++ functions use the Mu namespace
|
|
|
|
6. Non-global functions *don't* have the module prefix, and are declared
|
|
static.
|
|
|
|
7. Functions have their return type on a separate line before the function
|
|
name, so:
|
|
|
|
#+BEGIN_EXAMPLE
|
|
static int
|
|
foo (const char *bar)
|
|
{
|
|
....
|
|
}
|
|
#+END_EXAMPLE
|
|
|
|
8. In C code, variable-declarations are at the beginning of a block.
|
|
|
|
In C code, the declaration does *not* initialize the variable. This will
|
|
give the compiler a chance to warn us if the variable is not initialized
|
|
in a certain code path. Exception: autoptr & friends.
|
|
|
|
9. Returned strings of type ~char*~ must be freed by the caller; if they are
|
|
not to be freed, ~const char*~ should be used instead
|
|
|
|
10. Functions calls have a space between function name and arguments, unless
|
|
there are none, so:
|
|
|
|
~foo (12, 3)~;
|
|
|
|
and
|
|
|
|
~bar();~
|
|
|
|
after a comma, a space should follow.
|
|
|
|
11. C-functions that do not take arguments are explicitly declared as f(void)
|
|
and not f(). Reason: f() means that the arguments are /unspecified/ (in C)
|
|
|
|
12. C-code should not use ~//~ comments.
|
|
|
|
|
|
** Logging
|
|
|
|
For logging, mu uses the GLib logging functions/macros as listed below,
|
|
except when logging may not have been initialized.
|
|
|
|
The logging system redirects most logging to the log file (typically,
|
|
=~/.cache/mu/mu.log, or to the systemd journal=). ~g_critical~ messages are
|
|
written to stderr.
|
|
|
|
- ~g_message~ is for non-error messages the user will see (unless running with
|
|
~--quiet~)
|
|
- ~g_warning~ is for problems the user may be able to do something about (and
|
|
they are written on ~stderr~)
|
|
- ~g_critical~ is for mu bugs, serious, internal problems (~g_return_if_fail~ and
|
|
friends use this). (and they are written on ~stderr~)
|
|
- don't use ~g_error~
|
|
|
|
** Compiling from git
|
|
|
|
For hacking, you're strongly advised to use the latest git version.
|
|
Compilation from git should be straightforward, if you have the right tools
|
|
installed.
|
|
|
|
*** dependencies
|
|
|
|
You need to install a few dependencies; e.g. on Debian/Ubuntu:
|
|
#+BEGIN_EXAMPLE
|
|
sudo apt-get install \
|
|
automake \
|
|
autoconf-archive \
|
|
autotools-dev \
|
|
libglib2.0-dev \
|
|
libxapian-dev \
|
|
libgmime-3.0-dev \
|
|
m4 \
|
|
make \
|
|
libtool \
|
|
pkg-config
|
|
#+END_EXAMPLE
|
|
|
|
Then, to compile straight from ~git~:
|
|
|
|
#+BEGIN_EXAMPLE
|
|
$ git clone https://github.com/djcb/mu
|
|
$ cd mu
|
|
$ ./autogen.sh
|
|
$ make
|
|
#+END_EXAMPLE
|
|
|
|
You only need to run ~./autogen.sh~ the first time and after changes in the
|
|
build system; otherwise you can use ~./configure~.
|
|
|
|
# Local Variables:
|
|
# mode: org; org-startup-folded: nofold
|
|
# fill-column: 80
|
|
# End:
|