|
Size: 21189
Comment:
|
← Revision 190 as of 2023-09-13 15:46:41 ⇥
Size: 3992
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #pragma section-numbers on #acl WikiUserGroup:read,write,delete,revert All:read |
#acl LcnGroup:read,write,delete,revert All:read |
| Line 4: | Line 3: |
| '''Index''' | = FreeSurfer Dev Guide = |
| Line 6: | Line 5: |
| [[TableOfContents]] | * Visit the BuildGuide for instructions on building and installing freesurfer manually. * Visit the GitHub page for an introduction to the github workflow. * Visit the GitAnnex page for detailed instructions on using git annex for storing and retrieving large data files in the repository. |
| Line 8: | Line 9: |
| 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). | == File Size Limitations == |
| Line 10: | Line 11: |
| === CVS Checkout === | Any files '''larger than 50MB''' should be stored in the GitAnnex, following the hyperlinked instructions, and properly linked to your utility. |
| Line 12: | Line 13: |
| If you have an NMR account, you can checkout the FreeSurfer source code from the NMR center using local CVS access or remotely by using SSH as the CVS remote connection method. | == Adding a New C Program == |
| Line 14: | Line 15: |
| Internal to the NMR Center, there exists a [http://minerva:8080 CVSweb server] with [http://minerva:8080/cgi-bin/cvshistory.cgi CVShistory]. ==== Local CVS Access ==== The CVS repository is /space/repo/1/dev. Use this as your CVSROOT. You can either set it as an environment variable: |
If you'd like to add a new program to the tree, you should create a new subdirectory with the title of your tool. As an example, let's create a new c++ program called `mri_process`. First, we'll create a top-level subdirectory that contains our new c++ file and an empty `CMakeLists.txt` file: |
| Line 21: | Line 18: |
| setenv CVSROOT /space/repo/1/dev | freesurfer/ mri_process/ CMakeLists.txt mri_process.cpp |
| Line 24: | Line 24: |
| or specify it in the checkout command with the -d option. Note that the CVS root is cached in a CVS checkout directory, so if you choose to use the -d method, you will only have to do it once during your first checkout. Check out the code with the CVS checkout command. The archive name is dev. |
In order to configure our new code, we should add the following to the empty `CMakeLists.txt` file. |
| Line 29: | Line 27: |
| cvs checkout -P dev | project(mri_process) include_directories(${FS_INCLUDE_DIRS}) add_executable(mri_process mri_process.cpp) target_link_libraries(mri_process utils) install(TARGETS mri_process DESTINATION bin) |
| Line 32: | Line 37: |
| or | This will compile `mri_process.cpp`, link it against the `utils` freesurfer library, and copy the executable to the `$FREESURFER_HOME/bin` directory during install. To include this subdirectory in the main freesurfer build, make sure to modify the top-level `CMakeLists.txt` by adding `mri_process` to the long list of included directories at the bottom of the file. Now, after reconfiguring your build, you can run `make` in the `mri_process` directory of your build tree to successfully compile the new program. If you're having trouble configuring and building freesurfer, be sure to visit the BuildGuide for step-by-step instructions. == Adding a New Python Program == Adding a new python program is similar to adding a new c++ program, with an additional step of creating a bash wrapper to be installed in `$FREESURFER_HOME/bin`. * Note: Make sure all paths in the Bash wrapper that reference files in the FreeSurfer file tree are defined relative to `$FREESURFER_HOME`, to ensure they are found regardless of the install location As an example, let’s add a program called `mri_process` to the FreeSurfer tree, where the main functionality is in a python script called `mri_process.py`, and has a dependency on a model called `process_model.h5`. First, we’ll create a directory containing the scripts, dependencies, and `CMakeLists.txt`: |
| Line 35: | Line 49: |
| cvs -d /space/repo/1/dev checkout -P dev | freesurfer/ mri_process/ CMakeLists.txt mri_process.sh # shell wrapper to install in bin/ process_model.h5 # model dependency stored in the annex python/ # dir containing the python code mri_process.py # python script called by shell wrapper |
| Line 38: | Line 58: |
| This will copy the entire archive to your directory, creating a directory called dev/. The -P option will purge the old directories that have been removed from the CVS repository. | Now we’ll need to populate the empty `CMakeLists.txt` file. We need to achieve the following in this file: 1. Give the utility a project name 2. Link the python scripts to the location they are referenced by the Bash wrapper 3. Install the wrapper script into `$FREESURFER_HOME/bin` 4. Link any models to the proper location to be accessible to the python code |
| Line 40: | Line 64: |
| Generally it is handy to define an environment variable called FSDEV which is set to your Freesurfer development directory. Be sure also to define your FREESURFER_HOME environment variable set to the intended Freesurfer installation directory. | An example `CMakeLists.txt`: {{{ project(mri_process) |
| Line 42: | Line 68: |
| ==== Remote CVS Access ==== | install_symlinks(python/mri_process.py TYPE files DESTINATION python/scripts) |
| Line 44: | Line 70: |
| Tell CVS to use SSH to access the archive by setting the following environment variable: | install_configured(mri_process.sh DESTINATION bin) |
| Line 46: | Line 72: |
| {{{ setenv CVS_RSH ssh |
install_symlinks(process_model.h5 TYPE files DESTINATION models) |
| Line 50: | Line 75: |
| Use the following string as your CVS root: {{{ setenv CVSROOT :ext:USER@MACHINE.nmr.mgh.harvard.edu:/space/repo/1/dev }}} Where USER is your username and MACHINE is one of the NMR machines visible to the outside ('door', not 'gate'). Then use the CVS commands normally. Check out the code with the CVS checkout command. The archive name is dev. {{{ cvs checkout -P dev }}} Note that using this method makes an SSH connection for every CVS command, and you will be required to enter your password every time. You may want to look into a utility to automatically authenticate SSH connections, such as SSH agent. See: http://mah.everybody.org/docs/ssh When working in a CVS checkout directory, cvs knows where the CVSROOT is for that directory. However, it doesn't know what CVS_RSH method to use, so if you are grabbing files remotely, you may want to set this in your login file. === Open Source Distribution === '''not available just yet''' === Configuring === While not strictly necessary, NMR center developers are encouraged to run a pre-configure script, to create the platform specific tools required by configure (execute in the dev/ directory created by cvs checkout): {{{ ./setup_configure }}} This script runs a set of commands (aclocal, libtoolize, automake, autoconf) that creates the platform specific files for configure and puts them in the 'dev/config' directory. Those who are working with the open-source distribution should not need to run this script, as the default files should work for most platforms, but ./setup_configure is there if someone is having autoconf issues. 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. You will probably need to supply some extra options: {{{--prefix=~/work/freesurfer}}} The prefix option determines where your build will be installed when you use the 'make install' command. This is your private copy of FreeSurfer, not a release for others, so put it in your own directory space. Generally, a developer will set their $FREESURFER_HOME to their working directory (in this case FREESURFER_HOME is ~/work/freesurfer). If you are compiling in the NMR Center, pass the option: {{{--enable-nmr-install}}} This will look for and install some files that are only usable in the Center. These files are not included in external (open-source) release, so using this option on an external release will result in an error as required files will not be found. There are options to specify where certain packages exist, such as: {{{--with-mni-dir=/usr/pubsw/packages/mni/current}}} These are often needed so configure can find libraries installed in /usr/pubsw. Note that you should have /usr/pubsw mounted on your machine. This is normal for NMR computers. Freesurfer builds against the following set of open-sourced libraries, thus, these must be installed prior to building: * MNI 1.4 * VXL 1.7.0 * VTK 5.0.2 * Tcl 8.4.6 * Tk 8.4.6 * Tix 8.1.4 * BLT 2.4z * JPEG * TIFF * GLut If these libraries are not available on your system, then they must be built and installed. Special bundles of this open-source code are available on the distribution site: ftp://surfer.nmr.mgh.harvard.edu/pub/dist/fs_supportlibs Also in this 'bundle' directory is a Linux script called 'fs_lib_check' which will check your system for these libraries given some prior sysadmin installation. If you do not have a set of libs, then in the src directory are the .tar.gz files containing the open-source code from which they can be built. The files tcltktixblt.tar.gz, tiffjpegglut.tar.gz, and mni-1.4-srcbuild.tar.gz each contain special build scripts that perform the work of building and installing these libraries. Refer to those scripts (with 'build_' in the filename preface) to see what they do. The vxl-1.6.0 source requires cmake. Refer to the [http://vxl.sourceforge.net VXL home page] for build instruction. For the simplest installation, it is recommended to install these packages in a directory called {{{/usr/pubsw/packages}}}, as the Freesurfer setup script checks for this directory for its packages during its setup. Here is a table of recommended installation paths for the 3rd-party packages: || /usr/pubsw/packages/mni/current || mni-1.4-srcbuild.tar.gz || attachment:mni.srcbuild.README || || /usr/pubsw/packages/vxl/current || vxl-1.7.0.tgz || attachment:README-VXL-MGH.txt || || /usr/pubsw/packages/vtk/current || vtk-5.0.2.tar.gz || attachment:README-VTK-MGH.txt|| || /usr/pubsw/packages/tcltktixblt/current || tcltktixblt-8.4.6.tar.gz || || || /usr/pubsw/packages/tiffjpegglut (Mac OS X only) ||tiffjpegglut-1.1.tar.gz || || Freesurfer also builds against certain packages of the MINC toolkit. A special bundle of the MINC toolkit source code for the MINC packages required by Freesurfer has been assembled at MGH and is available from the download site: ftp://surfer.nmr.mgh.harvard.edu/pub/dist/fs_supportlibs/src Look for {{{mni-1.4-srcbuild.tar.gz}}}, and {{{mni.srcbuild.README.txt}}} describes the build process. A sample configure line for a Linux machine at the NMR center having appropriate NFS mount-points (ie. /usr/pubsw/packages): {{{ setenv LD_LIBRARY_PATH /usr/pubsw/packages/vxl/current/lib ./configure \ --enable-nmr-install \ --prefix="$FREESURFER_HOME" \ --with-mni-dir="/usr/pubsw/packages/mni/current" \ --with-vxl-dir="/usr/pubsw/packages/vxl/current" \ --with-vtk-dir="/usr/pubsw/packages/vtk/current" \ --with-tcl-dir="/usr/pubsw/packages/tcltktixblt/current" }}} A sample configure line for a Mac OS X machine at the NMR center having appropriate NFS mount-points (ie. /usr/pubsw/packages): {{{ setenv LD_LIBRARY_PATH /usr/pubsw/packages/vxl/current/lib ./configure \ --enable-nmr-install \ --prefix="$FREESURFER_HOME" \ --with-mni-dir="/usr/pubsw/packages/mni/current" \ --with-vxl-dir="/usr/pubsw/packages/vxl/current" \ --with-vtk-dir="/usr/pubsw/packages/vtk/current" \ --with-tcl-dir="/usr/pubsw/packages/tcltktixblt/current" \ --with-tixwish="/usr/pubsw/packages/tcltktixblt/current/bin/tixwish8.1.8.4" \ --with-pkgs-dir="/usr/pubsw/packages/tiffjpegglut" \ --with-glut-dir="/usr/pubsw/packages/tiffjpegglut" \ --with-gl-dir="/usr/X11R6" }}} Before attempting to build and install the 3rd-party packages from source, it is recommended to just start by running: {{{ ./configure \ --enable-nmr-install \ --prefix="$FREESURFER_HOME" }}} and observe the errors. configure will tell you which packages are already installed on your system. Read the file {{{config.log}}}, generated by configure, for error messages. Don't include the --enable-nmr-install option if building using an open-source distribution, as that distribution doesnt contain the nmr specialties. Be aware that the tcl/tk/tix/blt combo is particularly tricky. While many systems have tcl/tk installed, the tricky thing is getting tix and BLT to work with tcl/tk. Thus, our installation package (tcltktixblt.tar.gz) is the easiest route to successfully getting these four guys to work together. Also, if the --with-tcl-dir=DIR option is not included in the configure command, then the Tcl/Tk apps (tkmedit, tksurfer, tkregister, scuba and orient_mri) are not built. This handy if these GUI apps are not required (such as for a cluster machine). === Building === 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. 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: {{{ cd dev make -j 9 }}} 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. 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: {{{ cd mri_info make }}} This creates mri_info in the mri_info/ directory. === Adding a new binary to the tree === Assuming that you have a source file {{{MYPROG.c}}} that compiles into MYPROG and want to add it to the FreeSurfer tree: 1) Make the directory in dev and copy the source file there. Name the directory MYPROG and the source file {{{MYPROG.c}}}. {{{ mkdir dev/MYPROG cp MYPROG.c dev/MYPROG }}} 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). Be sure to add a backslash at the end of line: {{{ 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: {{{ bin_PROGRAMS = MYPROG }}} and also delete the notes that are there. d) Copy in the additional testing file {{{dev/dummy/myown.c}}}. You can customize it for your test program later. 3) Run {{{./set_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. {{{ [dev/]$ head config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by Freesurfer configure dev3, which was generated by GNU Autoconf 2.59. Invocation command line was $ ./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 }}} '''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). {{{ [dev/] cvs ci -m "Added MYPROG" configure 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 }}} === Installing === To install all binaries and support files into your private FreeSurfer, use 'make install' from the toplevel dev/ directory, like this: {{{ 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. {{{ cvs update -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. Additional stuff: To tag a group of code with a text label: {{{ cvs tag alpha-1 }}} To retrieve a tagged group of code: {{{ cvs update -r alpha-1 }}} There are more useful commands, but these are the most commonly used ones. See http://www.cvshome.org for more info. 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 }}} tag working files: {{{ cvs tag -c tag-name }}} if any working copies are edited, will report an error. check in first. checkout a tag: {{{ cvs checkout -r tag-name archive }}} split off a branch based on current revisions in working copy: {{{ cvs tag -b branch-name }}} note: doesn't make working copy the branch. split off a branch: {{{ cvs rtag -b -r tag-name branch-name archive }}} check out a branch: {{{ cvs checkout -r branch-name archive }}} switch working copy to a branch: {{{ cvs update -r branch-name archive }}} -or- {{{ BCD archive; cvs update -r branch-name }}} to find out what branch the working copy is on: {{{ cvs status }}} look for sticky tag field. join the changes in a branch to current working copy: {{{ cvs update -j branch-to-join file }}} best to tag merged branches after every merge. joing the changes in a revision to current working copy: {{{ cvs update -j rev file }}} i.e. two people check out 1.3, someone checks it in 1.4, you try to check it in and get a conflict, can join in the changes with cvs update -j 1.4 file.c 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 }}} To receive an email notification about any file that has been commited by somebody else: {{{ cd dev cvs watch add }}} To undo this, and disable receiving an email notification about files that have been commited, type: {{{ cd dev cvs watch remove }}} See also: [http://www.psc.edu/~semke/cvs_branches.html CVS Branch and Tag Primer] and [http://badgertronics.com/writings/cvs/keywords.html CVS Keywords] === Troubleshooting autoconf issues === [wiki:Self:AutoconfTroubleshooting Here's a list of common problems and solutions for autotools problems.] === Martinos Center issues === see [wiki:Self:DevelopersGuide/MartinosCenter Martinos Center issues] page === Coding Guide === This page deals specifically with coding issues. [wiki:Self:DevelopersGuide/CodingGuide CodingGuide] |
Finally, we need to add this directory to the list of included directories in the `CMakeLists.txt` located at the top level of the FreeSurfer file tree. To add your new utility to your build of FreeSurfer, reconfigure your build, and run make in the `mri_process` directory. You can also rebuild all of FreeSurfer with your new utility if needed. More information on building Freesurfer is located in the BuildGuide. |
FreeSurfer Dev Guide
Visit the BuildGuide for instructions on building and installing freesurfer manually.
Visit the GitHub page for an introduction to the github workflow.
Visit the GitAnnex page for detailed instructions on using git annex for storing and retrieving large data files in the repository.
File Size Limitations
Any files larger than 50MB should be stored in the GitAnnex, following the hyperlinked instructions, and properly linked to your utility.
Adding a New C Program
If you'd like to add a new program to the tree, you should create a new subdirectory with the title of your tool. As an example, let's create a new c++ program called mri_process. First, we'll create a top-level subdirectory that contains our new c++ file and an empty CMakeLists.txt file:
freesurfer/
mri_process/
CMakeLists.txt
mri_process.cppIn order to configure our new code, we should add the following to the empty CMakeLists.txt file.
project(mri_process)
include_directories(${FS_INCLUDE_DIRS})
add_executable(mri_process mri_process.cpp)
target_link_libraries(mri_process utils)
install(TARGETS mri_process DESTINATION bin)This will compile mri_process.cpp, link it against the utils freesurfer library, and copy the executable to the $FREESURFER_HOME/bin directory during install. To include this subdirectory in the main freesurfer build, make sure to modify the top-level CMakeLists.txt by adding mri_process to the long list of included directories at the bottom of the file. Now, after reconfiguring your build, you can run make in the mri_process directory of your build tree to successfully compile the new program. If you're having trouble configuring and building freesurfer, be sure to visit the BuildGuide for step-by-step instructions.
Adding a New Python Program
Adding a new python program is similar to adding a new c++ program, with an additional step of creating a bash wrapper to be installed in $FREESURFER_HOME/bin.
Note: Make sure all paths in the Bash wrapper that reference files in the FreeSurfer file tree are defined relative to $FREESURFER_HOME, to ensure they are found regardless of the install location
As an example, let’s add a program called mri_process to the FreeSurfer tree, where the main functionality is in a python script called mri_process.py, and has a dependency on a model called process_model.h5.
First, we’ll create a directory containing the scripts, dependencies, and CMakeLists.txt:
freesurfer/
mri_process/
CMakeLists.txt
mri_process.sh # shell wrapper to install in bin/
process_model.h5 # model dependency stored in the annex
python/ # dir containing the python code
mri_process.py # python script called by shell wrapperNow we’ll need to populate the empty CMakeLists.txt file. We need to achieve the following in this file:
- Give the utility a project name
- Link the python scripts to the location they are referenced by the Bash wrapper
Install the wrapper script into $FREESURFER_HOME/bin
- Link any models to the proper location to be accessible to the python code
An example CMakeLists.txt:
project(mri_process) install_symlinks(python/mri_process.py TYPE files DESTINATION python/scripts) install_configured(mri_process.sh DESTINATION bin) install_symlinks(process_model.h5 TYPE files DESTINATION models)
Finally, we need to add this directory to the list of included directories in the CMakeLists.txt located at the top level of the FreeSurfer file tree. To add your new utility to your build of FreeSurfer, reconfigure your build, and run make in the mri_process directory. You can also rebuild all of FreeSurfer with your new utility if needed. More information on building Freesurfer is located in the BuildGuide.
