ROSE Compiler Framework/Developer's Guide
We briefly describe the workflow of ROSE developers.
Basic skills for ROSE developers[edit | edit source]
Have experience with these, or be ready to learn them
- Shell programming: Bash (default shell)
- Unix commands: grep, find, ssh, etc.
- C++ programming
- Build systems
- CMake The windows port uses this, we are looking into using it elsewhere
- LaTeX: Documentation Standard
- Compiler Techniques: Intuition is invaluable
Helpful Resources[edit | edit source]
Valued Contributions[edit | edit source]
The ROSE project values the following contributions:
- Code: implementing new compiler features, improving existing work, passing code review and Jenkins. Only commits which were merged into the central master branch count as contributions.
- Expanding Language Support
- Analyses (AST analyses are a good place to start)
- Build System
- Bug Fixes: passing code review and Jenkins (in the future, Klocwork, Coverity, etc. analysis tools)
- Users bugs found in the SciDAC outreach center's bug tracker
- Internal bugs: Usually developer bugs, they can be found on github.com or redmine
- How ROSE Works
- Tutorial, Manual, FAQ, etc. (Updating these is most helpful)
- Project Documentation (projects can be found in the projects directory)
- Design/Architecture/API Documentation,
- Workflow Documentation
- System administration: Maintain and improve workflow components (mostly internal developer work, but suggestions are useful)
- Website: rosecompiler.org
- Git repository
- Project management: Redmine
- Code review: Github enterprise
- Jenkins: Continuous integration, improving testings
- Publications: technical reports, papers, presentations, posters
- Slides from presentations (Upload slides to relevant Redmine project's @Files Tab@. (@.pptx@ format is required)
- Collaborative proposals
Feedback: Remember that any problem you find is probably not unique to you
- General struggles (administratively or implementation-wise)
- General improvement/enhancement ideas for both the software and the people
Milestones for a ROSE developers[edit | edit source]
Having been working with some interns with us, we roughly identify the following milestones for a ROSE developer:
- Development environment: pick a platform of your choice (Linux or Mac OS), and get familiar with that specific platform (shell, editors, environment variable setting, etc.)
- Physical location: locations MATTER! Sit closer to people you should interact often. Make your desk/office accessible to others. Physically isolated office/desk may have very negative impact on your productivity.
- Installing ROSE: being able to smoothly configure, compile, and install ROSE
- Build system: being able to add a project (first skeleton) into ROSE by modifying Makefile.am, etc.
- Contribution following ROSE Coding Standard and passing code review
- Documentation: sufficient documentation about what you work is about
- Software Engineering:
- Style guidelines: Doxygen comments, naming conventions, where to put things, etc.
- Interface: Does the code has a clean and simple interface to be used by users?
- Algorithm design: documented by source comments how things are expected to work
- Coding implementation: correctly implement the designed algorithm
- Tests: Each contribution must have the accompanying tests to make sure it works as expected
- Continuous integration: push commits to be code reviewed and tested by Jenkins every two or three weeks for your incremental development results.
- Add a new test job if none of the existing ones tests your project
- Confirm your commits are merged into the ROSE project's central master branch: github.com provides graphs for individual impact
Termination checklist[edit | edit source]
We often have interns/collaborators/subcontractors finishing up their official duties with us. Here a brief checklist before their termination
- Complete the student program checklist (we have no idea what you need to do :-)
- Complete the performance evaluation form provided by us: mostly provide objective facts to demonstrate contributions since subjective impressions can be very off.
- Complete a short feedback form provided by us, where you can discuss anything related to developing ROSE or working with the ROSE team. Your candid feedback is essential to the future of our collaborative program.
- Schedule a one-to-one meeting with at least one staff member two weeks before the official end dates to do status check and plan the exit
- Turn in all documentations (LaTeX, word, powerpoint, etc) not in git repo by uploading them to the redmine project File tab
- Stop developing any new features at least one week before the end date so we can focus on making sure all source code contributions can pass Jenkins
- If you plan to continue collaborating with us, ask about getting internal access (e.g. VPN), or setup some other method for collaboration.
Code Review[edit | edit source]
See the Code Review section for details.
Working From An Internal LLNL Computer[edit | edit source]
Toolchain[edit | edit source]
There are many tools pre-installed on the /nfs/apps mount point:
$ ls /nfs/apps apr bin etc grace java mpc neon pygobject sqlite toolworks.old asciidoc binutils flex graphviz libtool mpfr openssh python src totalview asymptote blender gcc hdf5 m4 mpich perl qt subversion upc autoconf doc++ git insure++ maple mpich2 pgi rdesktop swig visit automake doxygen gmp intel matlab mplayer psi ruby texinfo xemacs
The root of most of these tools contains a setup.sh file which you can source. This will correctly setup your library path ($LD_LIBRARY_PATH) and program path ($PATH):
$ source /nfs/apps/gcc/4.5.0/setup.sh
This GCC setup.sh file should also source MPFR and GMP, but if not, please do it manually:
$ source /nfs/apps/mpfr/3.0.0/setup.sh $ source /nfs/apps/gmp/4.3.2/setup.sh
If you fail to properly source these dependencies, you may encounter this error:
/nfs/apps/gcc/4.3.2/libexec/gcc/x86_64-unknown-linux-gnu/4.3.2/f951: error while loading shared libraries: libmpfr.so.1: cannot open shared object file: No such file or directory