Nevar pievienot vairāk kā 25 tēmas Tēmai ir jāsākas ar burtu vai ciparu, tā var saturēt domu zīmes ('-') un var būt līdz 35 simboliem gara.

130 rindas
3.2 KiB

pirms 14 gadiem
pirms 13 gadiem
pirms 13 gadiem
  1. rebar
  2. =====
  3. rebar is an Erlang build tool that makes it easy to compile and
  4. test Erlang applications, port drivers and releases.
  5. rebar is a self-contained Erlang script, so it's easy to distribute or even
  6. embed directly in a project. Where possible, rebar uses standard Erlang/OTP
  7. conventions for project structures, thus minimizing the amount of build
  8. configuration work. rebar also provides dependency management, enabling
  9. application writers to easily re-use common libraries from a variety of
  10. locations (git, hg, etc).
  11. Building
  12. --------
  13. Information on building and installing Erlang/OTP can be found
  14. in the `INSTALL.md` document.
  15. ### Dependencies
  16. To build rebar you will need a working installation of Erlang R13B03 (or
  17. later).
  18. Should you want to clone the rebar repository, you will also require git.
  19. #### Downloading
  20. Clone the git repository:
  21. $ git clone git://github.com/basho/rebar.git
  22. #### Building rebar
  23. ```sh
  24. $ cd rebar
  25. $ ./bootstrap
  26. Recompile: src/getopt
  27. ...
  28. Recompile: src/rebar_utils
  29. ==> rebar (compile)
  30. Congratulations! You now have a self-contained script called "rebar" in
  31. your current working directory. Place this script anywhere in your path
  32. and you can use rebar to build OTP-compliant apps.
  33. ```
  34. Contributing to rebar
  35. =====================
  36. Pull requests and branching
  37. ---------------------------
  38. Use one topic branch per pull request.
  39. Do not commit to master in your fork.
  40. Provide a clean branch without any merge commits from upstream.
  41. Usually you should squash any intermediate commits into the original single commit.
  42. Code style
  43. ----------
  44. Do not introduce trailing whitespace.
  45. Do not mix spaces and tabs.
  46. Do not introduce lines longer than 80 characters.
  47. [erlang-mode (emacs)](http://www.erlang.org/doc/man/erlang.el.html) indentation is preferred.
  48. vi-only users are encouraged to give [Vim emulation](http://emacswiki.org/emacs/Evil) ([more info](https://gitorious.org/evil/pages/Home)) a try.
  49. Writing Commit Messages
  50. -----------------------
  51. Structure your commit message like this:
  52. <pre>
  53. One line summary (less than 50 characters)
  54. Longer description (wrap at 72 characters)
  55. </pre>
  56. ### Summary
  57. * Less than 50 characters
  58. * What was changed
  59. * Imperative present tense (fix, add, change)
  60. * `Fix bug 123`
  61. * `Add 'foobar' command`
  62. * `Change default timeout to 123`
  63. * No period
  64. ### Description
  65. * Wrap at 72 characters
  66. * Why, explain intention and implementation approach
  67. * Present tense
  68. ### Atomicity
  69. * Break up logical changes
  70. * Make whitespace changes separately
  71. Dialyzer and Tidier
  72. -------------------
  73. Before you submit a patch check for discrepancies with
  74. [Dialyzer](http://www.erlang.org/doc/man/dialyzer.html):
  75. ```sh
  76. $ make check
  77. ```
  78. The following discrepancies are known and safe to ignore:
  79. ```
  80. rebar_utils.erl:147: Call to missing or unexported function escript:foldl/3
  81. ```
  82. It is **strongly recommended** to check the code with
  83. [Tidier](http://tidier.softlab.ntua.gr:20000/tidier/getstarted).
  84. Select all transformation options and enable **automatic**
  85. transformation.
  86. If Tidier suggests a transformation apply the changes **manually**
  87. to the source code.
  88. Do not use the code from the tarball (*out.tgz*) as it will have
  89. white-space changes
  90. applied by Erlang's pretty-printer.