So you wanna code ?

This is by no way an "how to code" tutorial, but rather a small list of things to know before coding. When appropriate, we link to the appropriate resource.


We use subversion to keep track of our code, so you will need:
  • a subversion client: packages exists for most platforms, it's even possible that you already have it (try to run svn help from the command line), otherwise, see their webpage or your system administrator.
  • an access to our repository: this can only be granted by "le propriétaire"
We use trac for documentation, discussion, bug tracking, online source code browsing, coffee etc... so you probably want some specific access to this place, which will be granted in the same way as the svn access above. Please remember to authenticate and edit your preferences, we need your name and your email (for notifications).
We do use a few components from boost (I mean, this is a C++ project...), so you need to have a distribution somewhere.

About SubVersioN


The repository URL is, you're probably interested in the cubby project which expose the usual trunk, branches, tags hierarchy.


If you are not familiar with subversion, you should read the basic usage section of the book.

we provide 2 or 3 hours trainings too.


To do an initial checkout of the whole project:

alainm@satch:~/tmp$ svn co
A    cubby/trunk
A    cubby/trunk/force.cpp
A    cubby/trunk/Util_PostProcess
A    cubby/trunk/Util_PostProcess/makefile_gcc_jmfft
A    cubby/trunk/Util_PostProcess/pt_expand2.c
A    cubby/trunk/Util_PostProcess/makefile_pathscale_fftw

And of a single branch:

alainm@satch:~/tmp$ svn co
A    work/initial.hpp
A    work/Util_PostProcess
A    work/Util_PostProcess/deln

Commit/Interaction? with Trac

We use a commit hook so that our Trac tickets are automagically notified of the relevant commits. But you absolutely need to insert the corresponding messages in the commit message. From the hook documentation:

# Copyright (c) 2004 Stephen Hansen 
# ....
# It searches commit messages for text in the form of:
43	#   command #1
44	#   command #1, #2
45	#   command #1 & #2
46	#   command #1 and #2
47	#
48	# Instead of the short-hand syntax "#1", "ticket:1" can be used as well, e.g.:
49	#   command ticket:1
50	#   command ticket:1, ticket:2
#   command ticket:1 & ticket:2
#   command ticket:1 and ticket:2
# In addition, the ':' character can be omitted and issue or bug can be used
# instead of ticket.
# You can have more then one command in a message. The following commands
# are supported. There is more then one spelling for each command, to make
# this as user-friendly as possible.
#   close, closed, closes, fix, fixed, fixes
#     The specified issue numbers are closed with the contents of this
#     commit message being added to it.
#   references, refs, addresses, re, see
#     The specified issue numbers are left in their current status, but
#     the contents of this commit message are added to their notes.
# A fairly complicated example of what you can do is with a commit message
# of:
#    Changed blah and foo to do this or that. Fixes #10 and #12, and refs #12.
# This will close #10 and #12, and add a note to #12.


Our build system, which used to be based on Autoconf, as now been migrated to CMAKE.

Run CMake

If you are on a platform where all the components are "int the right place", you can generate the makfile simply by running cmake (or by running the equivalent gui enable tool, like cmake-gui).

If you are not on such a platform, two solutions:

  1. try to see if your machine is supported by the script (just run it, it will tell you), failing that...
  2. ... try to see if your machine looks like a machine supported by, if yes, be kind enough to add your line, failing that...
  3. ... look closer, in most cases, you only need to specify the location of the [ boost] and [ fftw] libraries, as in:
    cmake -DBOOST_ROOT:String='/opt/boost/' -DFFTW_ROOT:String='/opt/fftw/'

This will generate various files, among with the CMakeCache.txt file, which contains many interesting documented build configuration variables.

Release versus debug build

In the CMakeCache.txt, set the documented MAKE_BUILD_TYPE variable to switch between Debug and Release build.

Before Committing

Be sure to run the test, the rule is that at every commit, no matter how small and insignificant the change is, the tests should pass.

To run all the tests (from the code root directory)::

$ ctest
Start processing tests
Test project /home/alainm/views/codes/cubby/branches/trav
  1/ 47 Testing bug20                            Passed
 47/ 47 Testing hydro_penalization               Passed
100% tests passed, 0 tests failed out of 47

Running the tests in debug mode can be quite long, but might catch more bugs than in release mode, use your best judgment.

Last modified 11 years ago Last modified on Feb 23, 2010 10:35:46 PM