Differences between revisions 1 and 38 (spanning 37 versions)
Revision 1 as of 2016-09-02 17:39:08
Size: 13133
Editor: ZekeKaufman
Comment:
Revision 38 as of 2017-11-09 10:41:51
Size: 8196
Editor: AndrewHoopes
Comment:
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
<<TableOfContents(3)>> <<TableOfContents>>
Line 8: Line 8:
This page is targeted at those who have access to the FreeSurfer source code, and wish to build this source code on their own Unix platform (whether it be an NMR Martinos Center platform, which has all required libraries, or on some arbitrary Unix platform, where the dependent libraries must be installed prior to building FreeSurfer). This page is targeted at Martinos Center users who wish to inspect, build or develop within the Freesurfer code base. Non-Martinos users wishing to work with the Freesurfer code base should consult the [[http://surfer.nmr.mgh.harvard.edu/fswiki/freesurfer_linux_developers_page|read-only git repo]].
Line 10: Line 10:
=== Git Clone === === Getting the Source Code ===
Line 12: Line 12:
Users can download !FreeSurfer source code via the git repo: '''note:''' If you plan on actually contributing to the freesurfer repository, you should ignore this step and follow the instructions at [[https://surfer.nmr.mgh.harvard.edu/fswiki/Freesurfer_github|freesurfer_github]] to setup a github fork.

The first thing users at the Martinos Center need to do is '''prepend''' the directory {{{/usr/pubsw/packages/git-annex/current/bin}}} to their PATH. Once that is done, the Freesurfer source code can be cloned from the official [[https://github.com/freesurfer/freesurfer|Freesurfer github page]]:
Line 14: Line 17:
## Get source code files (206 MB)
$> git clone file:///space/freesurfer/repo/freesurfer
git clone git@github.com:freesurfer/freesurfer.git
Line 18: Line 20:
==== Getting the Data Files ====
The !FreeSurfer repository contains a large number data files, distributed via the {{{git-annex}}} software, which are not included with a default {{{git clone}}} of the repo. Users who only want the repository for the purposes of compiling binaries and/or inspecting source code, the {{{git clone}}} command from above is all you need to do. Users at the Center who want to run build time checks, or perform a full local installation, or just want all the contents of the repository, will need to run the following commands:
==== Get the Data Files ====
The Freesurfer repository contains a large number data files which are not included with a default {{{git clone}}} of the repo. Instead, these data files are distributed via the [[https://git-annex.branchable.com/|git-annex]] software. Users who only want the repository for the purposes of compiling binaries and/or inspecting source code, the {{{git clone}}} command from above is all you need to do. Users who want to run build time checks, or perform a full local installation, or just want all the contents of the repository, will need to add a special data store remote repository in order to retrieve these files.
Line 21: Line 23:

Put {{{git-annex}}} in your PATH:
To add the data store repository (this only needs to be done once):
Line 24: Line 25:
(bash)
$> export PATH=/usr/pubsw/packages/git-annex/current/bin:$PATH

(csh)
$> setenv PATH /usr/pubsw/packages/git-annex/current/bin:$PATH
git remote add datasrc file:///space/freesurfer/repo/annex.git
git fetch datasrc
Line 31: Line 29:
Get the data files: And to retrieve data files:
Line 33: Line 32:
$> git annex get . git annex get <filename>
Line 36: Line 35:
==== Remote git Access ==== The data files have been broken down into categories, those being required for build time checks, those required for a local installation, and everything else. Use one of the following commands depending on your needs:
Line 38: Line 37:
Outside of the Martinos Center, users can download !FreeSurfer source code via the read-only git repo:
Line 40: Line 38:
$> git clone https://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/repo/freesurfer.git ## Get only the data files required for build time checks (1.9 GB)
git annex get --metadata fstags=makecheck .

## Get only the data files required for local installation (4.3 GB)
git annex get --metadata fstags=makeinstall .

## Just give me everything! Not Recommended (6.8 GB)
git annex get .
Line 43: Line 48:
=== Configuring ===

It is necessary to run a pre-configure script, to create the platform specific tools required by configure (execute in the {{{freesurfer}}} directory created by {{{git clone}}}):
{{{
$> ./setup_configure
}}}
This script runs a set of commands (aclocal, libtoolize, automake v1.9.6, autoconf v2.59) that creates the platform specific files for configure and puts them in the 'dev/config' directory.

Now you need to configure your building parameters for your machine:
{{{
./configure
}}}
This runs the {{{configure}}} script which checks a bunch of local settings and libraries that are needed. Users at the Martinos Center should for the most part fine with the default settings, but the {{{configure}}} script does accept many options for pointing to specific libraries and other build specific parameters. Type {{{./configure --help}}} for a full list of options. The one exception is if a user want to perform a local installation of the freesurfer, he/she should use the {{{--prefix}}} flag. For example:

{{{
$> ./configure --prefix=~/work/freesurfer
}}}
Line 63: Line 51:
You can now run 'make', edit and build code, etc. The first thing you should do is 'make' to build libraries like libutils. (Note that all libs will be built to your local checkout directory.) To just build libutils, cd into utils/ and run make. ==== Setup Configure ====
Line 65: Line 53:
You can now compile individual programs or all of them at once. To compile all of them, just run 'make' from dev/. Binaries will automatically be placed in their individual subdirectories. Like this: It is necessary to run a pre-configure script, to create the platform specific tools required by configure (execute in the {{{freesurfer}}} directory created by {{{git clone}}}). This script runs a set of commands (aclocal, libtoolize, automake v1.9.6, autoconf v2.59) that creates the platform specific files for configure and puts them in the 'fsdev/config' directory.
Line 68: Line 56:
cd dev
make -j 9
./setup_configure
Line 72: Line 59:
Handy hint: the -j 9 option to make tells it to run nine simultaneous make processes, which, if building on a multi-processor machine, can speed-up the build. ==== Configure ====
Line 74: Line 61:
You may just want to compile one binary at a time, for instance, if you are developing an app. To do so, cd to the directory of the program you want and use 'make' to compile it: Now you need to configure your building parameters for your machine by running the {{{configure}}} script. Users at the Martinos Center should for the most part be fine with the default settings, but the {{{configure}}} script does accept many options for pointing to specific libraries and other build specific parameters. One exception is if a user wants to perform a local installation of !FreeSurfer, he/she should use the {{{--prefix}}} flag. Type {{{./configure --help}}} for a full list of options. For example:

{{{
## Default configuration
./configure

## Specify an installation location
./configure --prefix=~/freesurfer_install_dir

## See all possible options
./configure --help
}}}


Freesurfer builds against the following set of open-sourced libraries, which are installed under the {{{/usr/pubsw/packages}}} directory on all NMR computers:

 || Package || Version || || Package || Version ||
 || CUDA || v5.0.35-rh5 || || ANN || v1.1 ||
 || tiffjpegglut || v3.6, v6b, v3.7 || || itk || v3.16 ||
 || VTK || v5.6 || || VXL || v1.14 ||
 || MNI || v1.5 || || tcltktixblt || v8.4, v8.4, v8.1, v2.4z ||
 || KWWWidgets || CVS checkout || || Qt || v4.7 ||
 || wxWidgets || v2.8 || || cppunit || v1.10 ||
 || xawplus || v3.1 || || petsc || v2.3 ||

All these packages will be found by default by the {{{./configure}}} script. But there are options to specify where certain packages exists if a user wishes to build against a different version of one of the open-source libraries. For example:

{{{
## Specify a specific version of qt
./configure --with-qt=/usr/pubsw/packages/qt/4.8.5
}}}

==== Compile ====

You can now run 'make' to build the all individual programs in the !FreeSurfer source tree. Binaries will automatically be placed in their individual subdirectories.

{{{
make -j 4
}}}
''Handy hint: the -j 4 option to make tells it to run four simultaneous make processes, which, if building on a multi-processor machine, can speed-up the build.''

If you want to compile just one binary at a time, for example, if you are developing an app, than {{{cd}}} to the directory of the program you want and use 'make' to compile it:
Line 79: Line 107:
This creates mri_info in the mri_info/ directory. This creates mri_info in the mri_info/ directory. However, be aware the many program depends on the existence of libraries having already been build like libutils. Therefore users will need to build a few of the library directories first (e.g. utils, fsgdf, xml2, etc).

==== Install ====

To initial a local installation, type 'make install' from the top level directory:

{{{
make install
}}}

This will create a local Freesurfer installation in the directory as specified by the {{{--prefix}}} option to {{{configure}}} script (see above). Note that if you do not specify this location, it will try to install to /usr/local, which will probably require root access. The first time you run 'make install', it will take a while to copy all the big data files to the new installation. Subsequent 'make installs' will only copy the changed files.

If you only want to install a single binary, run 'make install' from a subdirectory. For example, running 'make install' from the {{{mri_convert}}} directory will copy the {{{mri_convert}}} binary to the proper locations. Running 'make install' from scripts/ will copy all the necessary scripts to the right location.
Line 83: Line 123:
Assuming that you have a source file {{{MYPROG.c}}} that compiles into MYPROG and want to add it to the FreeSurfer tree: For this example we will assume you want to create a program called 'MYPROG' and want to add it to the !FreeSurfer tree:
Line 85: Line 125:
1) Make the directory in dev and copy the source file there. Name the directory MYPROG and the source file {{{MYPROG.c}}}. 1) Make a directory called {{{MYPROG}}} under the {{{freesurfer}}} directory, and put your source code there. In the simplest case you will have a single source code file called {{{MYPROG.c}}}.
Line 88: Line 128:
mkdir dev/MYPROG
cp MYPROG.c dev/MYPROG
## Create the MYPROG directory and 'cd' into it
mkdir MYPROG
cd MYPROG
## The MYPROG.c file goes here
Line 92: Line 134:
2) Tell the autotools to build your program when you type {{{make}}} from the top dir:

 a) Modify {{{dev/configure.in}}} to add {{{MYPROG/Makefile}}} to the list of files in the definition of {{{AC_OUTPUT}}} (these are in roughly alphabetical order).

{{{
AC_OUTPUT(
... other files ...
MYPROG/Makefile
)
}}}

 b) Modify {{{dev/Makefile.am}}} to add {{{MYPROG}}} to the {{{SUBDIRS}}} definition. (You can also alternatively add it to the end of {{{MRISUBDIRS}}} or {{{MRISSUBDIRS}}} if more appropriate.)

{{{
SUBDIRS= ... other directories ... MYPROG
}}}

 c) Copy {{{dev/dummy/Makefile.am}}} into {{{MYPROG/}}} and customize it, replacing 'dummy' with 'MYPROG'. Be sure to change:
2) Copy {{{freesurfer/dummy/Makefile.am}}} into {{{MYPROG/}}} and customize it, replacing 'dummy' with 'MYPROG'. Also delete the notes that are there. Be sure to change:
Line 115: Line 140:
and also delete the notes that are there.
Line 117: Line 141:
 d) Copy in the additional testing file {{{dev/dummy/myown.c}}}. You can customize it for your test program later. 3) Modify {{{configure.in}}} to add {{{MYPROG/Makefile}}} to the list of files in the definition of {{{AC_OUTPUT}}} (these are in roughly alphabetical order).
Line 119: Line 143:
3) Run {{{./setup_configure}}} from {{{dev/}}}. This runs aclocal, autoconf and automake. You should get no errors. If you do, make sure you followed the above instructions properly. Also try the AutoconfTroubleshooting page. Verify that this step worked by checking if {{{MYPROG/Makefile.in}}} was created.

4) Run {{{./configure}}} with the parameters you previously used. To check these out, run {{{head config.log}}} from {{{dev/}}}, assuming you have run configure successfully on some prior occasion. The output should include the {{{./configure}}} line you used. Copy it, but leave out the {{{--no-create --no-recursion}}} options if present.
Line 124: Line 145:
[dev/]$ head config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
Line 128: Line 146:
It was created by Freesurfer configure dev3, which was
generated by GNU Autoconf 2.59. Invocation command line was
## configure.in ##
Line 131: Line 148:
  $ ./configure --prefix=/space/minerva/1/users/nicks/freesurfer \
--with-mni-dir=/usr/pubsw/packages/mni/current \
--with-vxl-dir=/usr/pubsw/packages/vxl/current \
--with-tcl-dir=/usr/pubsw/packages/tcltktixblt/current \
--with-tixwish=/usr/pubsw/packages/tcltktixblt/current/bin/tixwish8.1.8.4

## --------- ##
## Platform. ##
[dev/]$ /configure --prefix=/space/minerva/1/users/nicks/freesurfer \
--with-mni-dir=/usr/pubsw/packages/mni/current \
--with-vxl-dir=/usr/pubsw/packages/vxl/current \
--with-tcl-dir=/usr/pubsw/packages/tcltktixblt/current \
--with-tixwish=/usr/pubsw/packages/tcltktixblt/current/bin/tixwish8.1.8.4
AC_OUTPUT(
... <list of files> ...
MYPROG/Makefile
... <list of files> ...
)
Line 146: Line 155:
Note: Do not just copy this example, use what's in your own {{{config.log}}} file!

5) Run {{{make}}} and verify that your binary program {{{MYPROG/MYPROG}}} was created.

6) Check in your changes (note: do not commit Makefile.in, only Makefile.am is necessary).
4) Modify {{{freesurfer/Makefile.am}}} to add {{{MYPROG}}} to the {{{MRISUBDIRS}}} or {{{MRISSUBDIRS}}} definition. (You can also alternatively add it to the end of any of the *SUBDIRS categories.)
Line 153: Line 158:
[dev/] cvs ci -m "Added MYPROG" configure.in Makefile.am
[dev/] cvs add MYPROG
[dev/] cd MYPROG
[MYPROG/] cvs add Makefile.am MYPROG.c myown.c
[MYPROG/] cvs commit -m "First checkin." Makefile.am MYPROG.c myown.c

## Makefile.am ##

MRISUBDIRS= \
... <list of files> ...
MYPROG \
... <list of files> ...
Line 160: Line 167:
=== Installing === Once these 4 steps are complete MYPROG should automatically be built with the rest of !FreeSurfer. Try following the [[DevelopersGuide_git#Building|building steps from above]] to verify your binary compiles and builds successfully.
Line 162: Line 169:
To install all binaries and support files into your private FreeSurfer, use 'make install' from the toplevel dev/ directory, like this: === Contributing Changes ===
Users who with to contribute to the Freesurfer code base and/or commit changes to the repo should see the following page which describe how to fork the freesurfer repository and submit pull requests:
Line 164: Line 172:
{{{
cd dev
make install
}}}

This will make a directory called freesurfer/ in the directory specified by the --prefix option to configure, above. Note that if you do not specify this location, it will try to install to /usr/local, which you probably don't have permission to do. Even if you do, i.e. you are
installing on a laptop, it's generally better to specify a prefix of /usr/local/freesurfer to keep everything in the same place.

Note that you can also run 'make release'. 'make install' makes and installs the NMR internal version of FreeSurfer, while 'make release' makes the public version which omits some stuff.

The first time you run 'make install', it will take a while to copy all the big data files to the new installation. Subsequent 'make installs' will only copy the changed files.

If you only want to install a single binary, run 'make install' from a subdirectory. For example, running 'make install' from the scuba/ directory will copy the scuba binary and its support script files to the proper locations. Running 'make install' from scripts/ will copy all the necessary scripts to the right location.

=== Using CVS ===

When you want to commit your changes, use the cvs commit command. However, you must first check to see if the file(s) in the archive have changed since the last time you checked them out. To do so, run the cvs update command on the files you have changed. The -P option will purge (remove) files that have been removed from the CVS and the -d option will add any new directories that have been added since your last update (unsure why this isnt the default behavior).
{{{
cvs update -d -P
}}}
If any have changed, you will see the letter U followed by the file name.
{{{
U myFile.c
}}}
This means somebody else committed a newer version of the file, and your copy was just updated.

If you and somebody else have made changes on the same file that conflict each other, you will see the letter C along with a message about the conflicts.
{{{
C myFile.c
}}}
If the message states the conflicts have been resolved, you don't have to worry: cvs has merged the differences properly. If it says it couldn't merge the differences, you need to open the file in question, search for the string >>>, and merge the differences yourself.

Once the up to date check has been performed, you can commit your changes. If you are in a directory and want to commit all the files in that directory that you have changed, just use:
{{{
cvs commit
}}}
This will commit changes in the current directory and any subdirectories. If you want to commit only certain files, use:
{{{
cvs commit <filename>
}}}

Or you can only commit the code in the current directory with the -l switch:
{{{
cvs commit -l
}}}
Each time, an editor will open and ask you to enter a log message. To bypass this, use the -m option and enter your log message on the command line:
{{{
cvs commit -m "some descriptive changelog comment" <filename>
}}}
A synonym for commit is ci, so you can just:
{{{
cvs ci -m "fixed stuff" <filename>
}}}
Periodically, you should update your working copy to be in sync with the archive. CVS will look at all your files and see if the ones in the archive are different. If so, it will update your copy. CVS will not delete local modifications you have made. To do this update:
{{{
cvs update -d -P
}}}
The -d switch adds any new directories and is not strictly necessary, but is a good habit, because if you don't use it you will update existing files but will now add new directories. The -P option purges directories of files that have been removed in the past.

Similarly, you can update an entire directory or a single file. To commit all the code in the current directory (code that has not been changed will not be commited):
{{{
cvs ci -m "fixed many things"
}}}
To restore an edited version to the version in the archive, either delete the file and cvs update, and the archive version will be copied to the local work area, or use the -C option to cvs update to replace your copy with one from the archive.

To add a new file to the archive, use the add command and then commit the file:
{{{
cvs add <filename>
cvs commit -m "added the file" <filename>
}}}
To remove a file, remove in cvs and locally (with the -f flag), and commit:
{{{
cvs remove -f <filename>
cvs commit -m "removed the file" <filename>
}}}
That covers most of the CVS commands you'll have to to use.

For more info on CVS, check out www.cvshome.org or the CVS man pages.

Summary:

check in a file
{{{
cvs commit
}}}
get newest versions. merges newer versions than the ones you had with your working versions.
{{{
cvs update -A
}}}

add a new file:
{{{
cvs add file; cvs commit file
}}}

remove a file (but keep in older revisions):
{{{
rm file; cvs remove file; cvs commit file
}}}

rename a file:
{{{
mv old new; cvs remove old; cvs add new; cvs commit old new
}}}

See also: [[http://www.bioinf.uni-freiburg.de/~mmann/HowTo/cvs_branches.html|CVS Branch and Tag Primer]]
and [[http://badgertronics.com/writings/cvs/keywords.html|CVS Keywords]]

See also: [[DevelopersGuide/CVSTips]]

=== Troubleshooting autoconf issues ===

[[AutoconfTroubleshooting|Here's a list of common problems and solutions for autotools problems.]]

=== Martinos Center issues ===

see [[DevelopersGuide/MartinosCenter|Martinos Center issues]] page

Note: On this page, there are also instructions on how commit messages can be sent to an additional person for documentation purposes, etc.

=== Coding Guide ===

This page deals specifically with coding issues.

[[DevelopersGuide/CodingGuide|CodingGuide]]

=== Docs and Testing ===

[[NewProgramDocAndTest]]

=== Developing for a Mac ===

Info can be found [[http://surfer.nmr.mgh.harvard.edu/fswiki/freesurfer_mac_developers_page|here]].
  https://surfer.nmr.mgh.harvard.edu/fswiki/Freesurfer_github

Index

This page is targeted at Martinos Center users who wish to inspect, build or develop within the Freesurfer code base. Non-Martinos users wishing to work with the Freesurfer code base should consult the read-only git repo.

1. Getting the Source Code

note: If you plan on actually contributing to the freesurfer repository, you should ignore this step and follow the instructions at freesurfer_github to setup a github fork.

The first thing users at the Martinos Center need to do is prepend the directory /usr/pubsw/packages/git-annex/current/bin to their PATH. Once that is done, the Freesurfer source code can be cloned from the official Freesurfer github page:

git clone git@github.com:freesurfer/freesurfer.git

1.1. Get the Data Files

The Freesurfer repository contains a large number data files which are not included with a default git clone of the repo. Instead, these data files are distributed via the git-annex software. Users who only want the repository for the purposes of compiling binaries and/or inspecting source code, the git clone command from above is all you need to do. Users who want to run build time checks, or perform a full local installation, or just want all the contents of the repository, will need to add a special data store remote repository in order to retrieve these files.

To add the data store repository (this only needs to be done once):

git remote add datasrc file:///space/freesurfer/repo/annex.git
git fetch datasrc

And to retrieve data files:

git annex get <filename>

The data files have been broken down into categories, those being required for build time checks, those required for a local installation, and everything else. Use one of the following commands depending on your needs:

## Get only the data files required for build time checks (1.9 GB)
git annex get --metadata fstags=makecheck .

## Get only the data files required for local installation (4.3 GB)
git annex get --metadata fstags=makeinstall .

## Just give me everything! Not Recommended (6.8 GB)
git annex get .

2. Building

2.1. Setup Configure

It is necessary to run a pre-configure script, to create the platform specific tools required by configure (execute in the freesurfer directory created by git clone). This script runs a set of commands (aclocal, libtoolize, automake v1.9.6, autoconf v2.59) that creates the platform specific files for configure and puts them in the 'fsdev/config' directory.

./setup_configure

2.2. Configure

Now you need to configure your building parameters for your machine by running the configure script. Users at the Martinos Center should for the most part be fine with the default settings, but the configure script does accept many options for pointing to specific libraries and other build specific parameters. One exception is if a user wants to perform a local installation of FreeSurfer, he/she should use the --prefix flag. Type ./configure --help for a full list of options. For example:

## Default configuration
./configure

## Specify an installation location
./configure --prefix=~/freesurfer_install_dir

## See all possible options
./configure --help

Freesurfer builds against the following set of open-sourced libraries, which are installed under the /usr/pubsw/packages directory on all NMR computers:

  • Package

    Version

    Package

    Version

    CUDA

    v5.0.35-rh5

    ANN

    v1.1

    tiffjpegglut

    v3.6, v6b, v3.7

    itk

    v3.16

    VTK

    v5.6

    VXL

    v1.14

    MNI

    v1.5

    tcltktixblt

    v8.4, v8.4, v8.1, v2.4z

    KWWWidgets

    CVS checkout

    Qt

    v4.7

    wxWidgets

    v2.8

    cppunit

    v1.10

    xawplus

    v3.1

    petsc

    v2.3

All these packages will be found by default by the ./configure script. But there are options to specify where certain packages exists if a user wishes to build against a different version of one of the open-source libraries. For example:

## Specify a specific version of qt
./configure --with-qt=/usr/pubsw/packages/qt/4.8.5

2.3. Compile

You can now run 'make' to build the all individual programs in the FreeSurfer source tree. Binaries will automatically be placed in their individual subdirectories.

make -j 4

Handy hint: the -j 4 option to make tells it to run four simultaneous make processes, which, if building on a multi-processor machine, can speed-up the build.

If you want to compile just one binary at a time, for example, if you are developing an app, than cd to the directory of the program you want and use 'make' to compile it:

cd mri_info
make

This creates mri_info in the mri_info/ directory. However, be aware the many program depends on the existence of libraries having already been build like libutils. Therefore users will need to build a few of the library directories first (e.g. utils, fsgdf, xml2, etc).

2.4. Install

To initial a local installation, type 'make install' from the top level directory:

make install

This will create a local Freesurfer installation in the directory as specified by the --prefix option to configure script (see above). Note that if you do not specify this location, it will try to install to /usr/local, which will probably require root access. The first time you run 'make install', it will take a while to copy all the big data files to the new installation. Subsequent 'make installs' will only copy the changed files.

If you only want to install a single binary, run 'make install' from a subdirectory. For example, running 'make install' from the mri_convert directory will copy the mri_convert binary to the proper locations. Running 'make install' from scripts/ will copy all the necessary scripts to the right location.

3. Adding a new binary to the tree

For this example we will assume you want to create a program called 'MYPROG' and want to add it to the FreeSurfer tree:

1) Make a directory called MYPROG under the freesurfer directory, and put your source code there. In the simplest case you will have a single source code file called MYPROG.c.

## Create the MYPROG directory and 'cd' into it
mkdir MYPROG
cd MYPROG
## The MYPROG.c file goes here

2) Copy freesurfer/dummy/Makefile.am into MYPROG/ and customize it, replacing 'dummy' with 'MYPROG'. Also delete the notes that are there. Be sure to change:

bin_PROGRAMS = MYPROG

3) Modify configure.in to add MYPROG/Makefile to the list of files in the definition of AC_OUTPUT (these are in roughly alphabetical order).

## configure.in ##

AC_OUTPUT(
... <list of files> ...
MYPROG/Makefile
... <list of files> ...
)

4) Modify freesurfer/Makefile.am to add MYPROG to the MRISUBDIRS or MRISSUBDIRS definition. (You can also alternatively add it to the end of any of the *SUBDIRS categories.)

## Makefile.am ##

MRISUBDIRS= \
... <list of files> ...
MYPROG \
... <list of files> ...

Once these 4 steps are complete MYPROG should automatically be built with the rest of FreeSurfer. Try following the building steps from above to verify your binary compiles and builds successfully.

4. Contributing Changes

Users who with to contribute to the Freesurfer code base and/or commit changes to the repo should see the following page which describe how to fork the freesurfer repository and submit pull requests: