diff --git a/.dir-locals.el b/.dir-locals.el deleted file mode 100644 index 3a491ef9..00000000 --- a/.dir-locals.el +++ /dev/null @@ -1,2 +0,0 @@ -((emacs-lisp-mode - (indent-tabs-mode . nil))) diff --git a/.travis.yml b/.travis.yml deleted file mode 100644 index 063324ac..00000000 --- a/.travis.yml +++ /dev/null @@ -1,35 +0,0 @@ -language: c -sudo: required -compiler: - - gcc -env: - global: - - BUILD_PKGS="libtool autoconf autoconf-archive automake texinfo" - - BUILD_LIBS="libgmime-2.6-dev libxapian-dev guile-2.0-dev libwebkitgtk-dev" - - TEST_PKGS="pmccabe" - matrix: - - EVM_EMACS=emacs-24.1-bin - - EVM_EMACS=emacs-24.2-bin - - EVM_EMACS=emacs-24.3-bin - # - EVM_EMACS=emacs-24.5-travis - # - EVM_EMACS=emacs-25.1-travis -before_install: - - git submodule update --init --recursive - # The Ubuntu version on travis is way too old, need Autoconf 2.69 - - sudo add-apt-repository ppa:dns/gnu -y - - sudo apt-get -qq update - - sudo apt-get install -qq ${BUILD_PKGS} ${BUILD_LIBS} ${TEST_PKGS} -install: - - sudo mkdir /usr/local/evm - - sudo chown $(id -u):$(id -g) /usr/local/evm - - curl -fsSkL https://raw.github.com/rejeep/evm/master/go | bash - - export PATH="$HOME/.evm/bin:$PATH" - - evm install $EVM_EMACS --use -script: - # Need recent version of autoconf-archive - - curl http://nl.mirror.babylon.network/gnu/autoconf-archive/autoconf-archive-2016.09.16.tar.xz -o /tmp/aa.tar.xz && tar xf /tmp/aa.tar.xz - - cp autoconf-archive-2016.09.16/m4/*.m4 m4/ - - ./autogen.sh - - ./configure - - make - - make check diff --git a/HACKING b/HACKING deleted file mode 100644 index 59b1d0ea..00000000 --- a/HACKING +++ /dev/null @@ -1,130 +0,0 @@ -* 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: diff --git a/Makefile.am b/Makefile.am index 641300dc..1120fb33 100644 --- a/Makefile.am +++ b/Makefile.am @@ -44,7 +44,6 @@ tags: EXTRA_DIST= \ TODO \ - HACKING \ README.org \ gtest.mk \ NEWS \