You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

130 line
3.3 KiB

14 年之前
14 年之前
  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. $ cd rebar/
  24. $ ./bootstrap
  25. Recompile: src/getopt
  26. ...
  27. Recompile: src/rebar_utils
  28. ==> rebar (compile)
  29. Congratulations! You now have a self-contained script called "rebar" in
  30. your current working directory. Place this script anywhere in your path
  31. and you can use rebar to build OTP-compliant apps.
  32. Contributing to rebar
  33. =====================
  34. Pull requests and branching
  35. ---------------------------
  36. Use one topic branch per pull request.
  37. Do not commit to master in your fork.
  38. Provide a clean branch without any merge commits from upstream.
  39. Usually you should squash any intermediate commits into the original single commit.
  40. Code style
  41. ----------
  42. Do not introduce trailing whitespace.
  43. Do not mix spaces and tabs.
  44. Do not introduce lines longer than 80 characters.
  45. [erlang-mode (emacs)](http://www.erlang.org/doc/man/erlang.el.html) indentation is preferred.
  46. vi-only users are encouraged to give [Vimpulse](http://www.emacswiki.org/emacs/Vimpulse) a try.
  47. Writing Commit Messages
  48. -----------------------
  49. Structure your commit message like this:
  50. <pre>
  51. One line summary (less than 50 characters)
  52. Longer description (wrap at 72 characters)
  53. </pre>
  54. ### Summary
  55. * Less than 50 characters
  56. * What was changed
  57. * Imperative present tense (fix, add, change)
  58. > Fix bug 123
  59. > Add 'foobar' command
  60. > Change default timeout to 123
  61. * No period
  62. ### Description
  63. * Wrap at 72 characters
  64. * Why, explain intention and implementation approach
  65. * Present tense
  66. ### Atomicity
  67. * Break up logical changes
  68. * Make whitespace changes separately
  69. Dialyzer and Tidier
  70. -------------------
  71. Before you submit a patch check for discrepancies with
  72. [Dialyzer](http://www.erlang.org/doc/man/dialyzer.html):
  73. <pre>
  74. $ cd rebar/
  75. $ ./bootstrap debug
  76. $ dialyzer ebin -Wunmatched_returns -Werror_handling -Wrace_conditions -Wunderspecs
  77. </pre>
  78. The following discrepancies are known and safe to ignore:
  79. <pre>
  80. rebar_utils.erl:147: Call to missing or unexported function escript:foldl/3
  81. rebar_utils.erl:180: The created fun has no local return
  82. </pre>
  83. It is **strongly recommended** to check the code with
  84. [Tidier](http://tidier.softlab.ntua.gr:20000/tidier/getstarted).
  85. Select all transformation options and enable **automatic**
  86. transformation.
  87. If Tidier suggests a transformation apply the changes **manually**
  88. to the source code.
  89. Do not use the code from the tarball (*out.tgz*) as it will have
  90. white-space changes
  91. applied by Erlang's pretty-printer.