1. NextGenCode

a grab-bag of notes on what we'd like to see in the ideal freesurfer source code environment, and runtime

1.0.1. Newer respository

• evaluate DVCS like git. if not something relatively modern like SVN which lets you do admin operations easily unlike CVS.
• source only checkout which excludes all distribution data. For faster and thinner local builds.

1.0.2. CMake building

• cmake replacing autotools as the build enviro

1.0.3. Third-Party Packages

• one-stop-shopping build of all 3rd party packages --> like neurodebian

• evaluate necessity of 3rd-party packages, eg PetSc

1.0.4. Source Code cleanups

• continued source code cleanup:
  • remove all #if 0 code and duplicated stuff
• source code documentation
• more low-level unit tests

1.0.5. GPU Transition

• memory structures changed to allow easier cpu (and gpu) parallelization (see rge notes)

1.0.6. recon-all

• complete replacement of recon-all with ????

1.0.7. Installation details

• eliminate clutter in $FREESURFER_HOME ( for the installation ).

  • for instance, the distribution data after installation should be in $FREESURFER_HOME/data. GEMS, the newest FS package, already uses this. It's data is in $FREESURFER_HOME/data/GEMS

1.0.8. Scripting language support

First phase is to wrap IO and utils so that it's possible for everyone to write scripts (Python, Numpy) in FreeSurfer instead of adding binaries to the source distribution. evaluate Cython as possible means.

When done properly, instead of adding a directory ( by mimicking the dummy/ project we have ) and toying with the Autotools, one can simply write a Python script like following:

import fs.utils as u
import fs.io as io

im = io.MRIread('test.mgz')
m = u.MRImean(im, 5)

1.0.9. Code Style Uniformization

• Use some standard for C89 and C++0x - e.g. [http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml] and [http://code.google.com/p/google-styleguide/]

• Avoid mixing C and C++ styles (in C++ use templates, Boost libraries, etc)