Bugs
Bugs should be filed in our bug tracker. Questions and comments can be sent to the developer mailing list: ramcloud-dev. (As of 2019/10/7 support for RAMCloud has ended)
Necessary Tools
- GNU Make (Anything reasonably recent)
- GNU g++ (4.4.*; later versions will require minor code modifications9.x)
- git (>= 1.6.0)
- Perl (Anything reasonably recent)
- For mergedeps.pl, which automatically inserts included headers in source files into the make dependencies.
- Python 2.6, epydoc
- Boost
- If you're having issues with Boost on Ubuntu, check boost ticket #3844.
- pcre
- Doxygen 1.7.21
- protocol buffers
- If you're getting lots of undefined reference errors during linking, it's likely that your libprotobuf is compiled with a different library ABI than RAMCloud. Check GCC's Dual ABI page and the "GLIBCXX_USE_CXX11_ABI" flag in GNUMakefile.
- ZooKeeper
- java and javac (>= 1.7.0_25)
To get a working toolchain on Debian (and probably Ubuntu), this used to be sufficient:
...
Here are some toolchain installation commands that have worked for other members of the community on different systems:
| OS | Command |
|---|---|
| Ubuntu 15.04 / Debian 8.2 | apt-get install build-essential git-core doxygen= |
Source Code
For Core Developers
...
Use the same instructions as above, except replace "git@github.com:PlatformLab/RAMCloud.git" with "https://github.com/PlatformLab/RAMCloud.git" in the git clone command. With this approach you don't need to have r+w access to the repository on GitHub, and you can't push commts commits to the repository. With read-only access, you can send us patches, or we can pull them from your repository.
...
- No commit should include changes for multiple issues. (Each commit in the push should complete or work towards a single issue.)
- Pushes should complete any issues they start, but individual commits within a push do not need to complete an issue.
- If at all possible, each commit should represent a version of the system that actually works (e.g., passes all unit tests and runs simple apps and system tests). This is important so that people can use
git bisectto hunt down the commit that caused a bug: if commits are broken,git bisectwon't work. - All commit messages should be meaningful without looking at the diff. (By reading a commit message, you should get some idea of what was modified and what the intent was. If you can't fit this in one line, skip a line and then write more.)
Speed Up Build
Put the following lines in the file `private/MakefragPrivateTop`:
| No Format |
|---|
# Use ccache to speed up compilation by caching object
# files across compilations.
CCACHE := yes
# Use gold linker for faster linking.
LINKER := gold |
Running Under Valgrind
Compiling unit test:
...
| No Format |
|---|
scripts/cluster.py --verbose --timeout=600 --valgrind --valgrindArgs='--leak-check=yes --leak-resolution=med --show-reachable=no --undef-value-errors=no' --client=RAM-462/ram462test |
Running With Google's Sanitizers
There are currently three Sanitizers available in the build option: AddressSanitizer (ASan), ThreadSanitizer (TSan) and UndefinedBehaviorSanitizer (UBSan). They can be enabled with the SANITIZER symbol. Different Sanitizers are not consistent with each other, so there can be only one Sanitizer enabled at a time.
Building RAMCloud and unit tests with ASan: Similarly, replace 'address' with 'thread' or 'undefined' to enable TSan or UBSan respectively.
| No Format |
|---|
make SANITIZER=address tests |
Running unit tests and system tests are the same as usual once RAMCloud and the respective test files are compiled with the Sanitizer.
For more information (e.g., the kinds of bugs each Sanitizer can find, bug report format, additional runtime options, etc.), see: https://github.com/google/sanitizers/wiki
Additional Sanity Checks
Before pushing to the master branch on fiz it is generally a good idea to make sure your changes haven't caused regressions in the recovery system.
...