jerryscript/05.dev-guide.md

layout	title	permalink
page	Development	/dev-guide/

Prerequisites setup

Upon first build, make would try to setup prerequisites, required for further development and precommit testing:

• stm32f3 and stm32f4 libraries
• nuttx's headers
• cppcheck 1.66
• vera++ 1.2.1

However, there are some dependencies, that should be installed manually:

• gcc / g++ (recommended >= 4.8.2)

  • native
  • arm-none-eabi

  sudo apt-get install gcc-arm-none-eabi
  

• cmake >= 2.8.12.2

• make >= 3.81

• bash >= 4.3.11

• cppcheck requires libpcre

  sudo apt-get install cmake libpcre3 libpcre3-dev
  

• vera++ requires tcl, tk and boost

  sudo apt-get install tcl8.6 tcl8.6-dev tk8.6-dev
  sudo apt-get install libboost-all-dev
  

Several shell utilities:

• find
• bc
• awk
• sed
• sha256sum
• wget

Proposals, Get Answers and Report a Bug via Github Issues

If you have a question about JerryScript code, have trouble any documentation, would like to suggest new feature, or find a bug, review the current JerryScript issues in GitHub, and if necessary, create a new issue.

There are several labels on the Issue. Please choose proper labels on the purpose.

• bug
• enhancement : feature enhancement proposal
• feature request : new feature proposal
• question : any questions on the project

and so on.

---

Patch Submission Process

If your patchset include a new feature, please discuss with community members in advance via Github Issues. When you're confident with your patchset, please submit your patch by following steps.

1. Scope the patch

Smaller patches are generally easier to understand and test, so please submit changes in the smallest increments possible.

2. Sign your work with the JerryScript DCO

The sign-off is a simple line at the end of the explanation for the patch, which certifies that you wrote it or otherwise have the right to pass it on as an Open Source patch. The sign-off is required for a patch to be accepted.

3. Open a Github pull request

4. Code review

Code review can be performed by all the members of the Project (not just Maintainers and Committers). Members can review code changes and share their opinion by comments with the following principles:

• Discuss code; never discuss the code's author.
• Respect and acknowledge contributions, suggestions, and comments.
• Listen and be open to all different opinions.
• Help each other.

Changes are submitted via pull requests and only the Maintainers and Committers should approve or reject the pull request.

5. Maintain the code

When the patches are accepted through proper review process and integrated into the master branch, please keep in mind that you have a responsibility to maintain the code throughout its lifecycle.