ROSE Compiler Framework/Developer's Guide

We briefly describe the workflow of ROSE developers.

Basic skills for ROSE developers

Have experience with these, or be ready to learn them

• Shell programming: Bash (default shell)
• Unix commands: grep, find, ssh, etc.
• C++ programming
• GDB/Valgrind
• Git
• Build systems
  • Make
  • CMake The windows port uses this, we are looking into using it elsewhere
  • autoconf/automake
  • libtool
• LaTeX: Documentation Standard
• Compiler Techniques: Intuition is invaluable

Helpful Resources

• Git
  • http://www.mediawiki.org/wiki/Git/Tutorial
  • http://eagain.net/articles/git-for-computer-scientists/

Valued Contributions

The ROSE project values the following contributions:

Development:

• 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)
  • Optimizations
  • 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
• Documentation:
  • 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

Research:

• Publications: technical reports, papers, presentations, posters
• Slides from presentations (Upload slides to relevant Redmine project's @Files Tab@. (@.pptx@ format is required)

Proposal:

• 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

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
  • https://github.com/rose-compiler/rose/commits?author=author_email_here

Termination checklist

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

See the Code Review section for details.

Working From An Internal LLNL Computer

Toolchain

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):

GCC

$ 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