User documentation for the ROSE compiler project.
This is a work in progress.
The purpose of this documentation is to make it easy for users to get up and running with ROSE.
Please check out the full documentation http://rosecompiler.org/documents.html
Google is your friend
Use Google to search the firstname.lastname@example.org mailing list.
For example, to get help with "Array Dimensions" in ROSE:
Please open Issues at rose-compiler/rose.
These issues will have the
Please refer to submitting_issues.md for guidelines on submitting an Issue (request/bug/enhancement).
Please share your nifty ROSE tips, tricks, and recipes with us!
All documentation must be written in Markdown (not in GitHub Flavored Markdown).
Please use the
.md extension only.
- Fork rose-compiler/rose-docs
- Develop on the master branch (default after
- Rebase your branch so that all your changes are reflected in one commit
- Push to your GitHub repository -
git push origin master
- Create a Pull Request from your GitHub repository, include as much as you can in the commit message/pull request, following these guidelines on writing a good commit message
- That's it!
Please follow some standard coding guidelines, such as those used by Google-originated open-source projects http://code.google.com/p/google-styleguide/
_instead of hyphens
-in file and directory names (e.g.
Annotate source code clearly. Make it helpful!
Each tutorial should be:
fully-contained in its own directory
a. containing an in-depth explanation
b. containing example code that
- fully demonstrates the tutorial's content, (a)
- actually works (with minor adjustments to the
rose-docs/ | |-- tutorials/ | | | |--ast-traversals (1) | | | | | |--hello (2) | | | | | | | |--README.md (a) | | | | | | | |--example1/ (b) | | | | |--Makefile | | | | `--main.cpp | | | | | | | |--example2/ | | | | |--Makefile | | | | |--header.h | | | | `--main.cpp | | | | | | | `--example3/ | | | | ... | | | ... | | | | | | | |--ast-rewrites | | | | | |--foo ... | | | ... ... ...
In the future, documentation components may be separated out into their own GitHub repositories to make use of independent issue tracking, etc.
Documentation may be converted to other formats as necessary. Therefore, the portability of our documentation is critical. This is one reason why we want to make sure we're conforming to standard practices and technologies.