1. NextGenCode

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

1.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 (atlases, subjects, templates). For faster and thinner local builds.

• Integrate an Issue tracking system. If FS is open source maybe Github or Google Code or even SourceForge are good ideas

1.2. CMake building and DartBoard

• cmake replacing autotools as the build enviro

• use a DartBoard to post nightly build and test results, like this page for MNE

1.3. Third-Party Packages

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

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

• MINC - the MNC file definitition (hence source code) is heavily integrated into freesurfer's data structures. extricating it would be very difficult. options include: including the relevant MNC source into the freesurfer tree. or, biting the bullet and decoupling it completely (although i think you'd just end-up with something that looks and acts exactly like the mnc code, just called something different, so we might as well just include the mnc source).

1.4. Mac OS, and cluster OS build support

• any overhaul must support seemless building under the Mac OS, and various oddball cluster OS's

1.5. TCL/TK and others

• Libraries that could be removed
  • Tcl/Tk/Tix/BLT/KWWidgets
• QT for GUI

1.6. Source Code cleanups

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

1.7. GPU Transition

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

1.8. recon-all

• complete replacement of recon-all with ???? (eliminate flags entirely and encapsulate dependencies)
• or further testing of 'make' as the central driver for recon-all

1.9. 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

• maintain current simple installation (untar a tarball anywhere); no installation script, no root priviledge requirement.

1.10. 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.11. 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)

2. Distribution

2.1. Better Compiler

• Intel Compiler licensing for making better binaries
• Rely on Dynamic Libraries to reduce the footprint of the distribution

2.2. Versioning Cycle

• Do not patch versions. Use the .x.x system to release small fixes
• Make it clear to users which versioning make it necessary to run again the recon-all