1. ITK Lecture 12: Open Source & Cross Platform Software Development Methods in Image Analysis CMU Robotics Institute 16-725 U. Pitt Bioengineering 2630 Spring Term, 2006 Methods in Image Analysis CMU Robotics Institute 16-725 U. Pitt Bioengineering 2630 Spring Term, 2006

2. Why this lecture exists  Successfully managing any software project is not an easy job  There are a lot of tools out there that make your life easier  Some we’ve talked about, some we haven’t  Successfully managing any software project is not an easy job  There are a lot of tools out there that make your life easier  Some we’ve talked about, some we haven’t

3. CMake  You should now be very familiar with CMake, what it does, and why it’s important  CMake is a pretty unique tool - be sure to keep it in mind for future projects  You should now be very familiar with CMake, what it does, and why it’s important  CMake is a pretty unique tool - be sure to keep it in mind for future projects

4. Revision control  Allows many developers to change a common code base simultaneously  Revision control of ASCII text files is easy; binary files are harder  Allows many developers to change a common code base simultaneously  Revision control of ASCII text files is easy; binary files are harder

5. CVS  Basic CVS operations are pretty simple; favorite GUI client is TortoiseCVS  CVS server configuration:  pserver - relatively easy to configure on the client side, low security  SSH - high security, client & server configuration a bit trickier  Basic CVS operations are pretty simple; favorite GUI client is TortoiseCVS  CVS server configuration:  pserver - relatively easy to configure on the client side, low security  SSH - high security, client & server configuration a bit trickier

6. CVS benefits  “Reference” version control software - many different client applications  Does the job well enough to require serious thought before replacing  “Reference” version control software - many different client applications  Does the job well enough to require serious thought before replacing

7. CVS problems  Security!  The normal pserver security is poor at best  SSH security is much better, but much trickier to use  Some odd side effects of versioning - can’t delete directories  Security!  The normal pserver security is poor at best  SSH security is much better, but much trickier to use  Some odd side effects of versioning - can’t delete directories

8. Subversion  A newer CVS alternative, core syntax is identical  Server configuration:  Apache web server  svnserve - custom server  svnserve & ssh - custom server with encryption layer  A newer CVS alternative, core syntax is identical  Server configuration:  Apache web server  svnserve - custom server  svnserve & ssh - custom server with encryption layer

9. Subversion benefits  More capable versioning core - directory deletion a legal operation  More flexible configuration options  Fewer security issues  More capable versioning core - directory deletion a legal operation  More flexible configuration options  Fewer security issues

10. Subversion problems  Fewer clients available  Windows (Tortoise SVN)  Mac (SVNx)  Command line (most other Unixes)  Fewer clients available  Windows (Tortoise SVN)  Mac (SVNx)  Command line (most other Unixes)

11. Version control interaction  Use CVSWeb to provide HTML access to a CVS repository  Subversion supports native HTML access to the repository  Useful for viewing differences between file versions  Use CVSWeb to provide HTML access to a CVS repository  Subversion supports native HTML access to the repository  Useful for viewing differences between file versions

12. Code testing  How to keep track of multiple OS’s and continuous revision of a common codebase?  Option 1… don’t worry  Option 2… use a testing framework  How to keep track of multiple OS’s and continuous revision of a common codebase?  Option 1… don’t worry  Option 2… use a testing framework

13. DART  Dashboard generator  Coordinates builds and tests from multiple sources  Client produces build/test results in XML  Server converts XML to HTML web pages  Supports continuous build process  Dashboard generator  Coordinates builds and tests from multiple sources  Client produces build/test results in XML  Server converts XML to HTML web pages  Supports continuous build process

14. DART, cont.

15. Graphics Toolkits/Libraries  Low level: OpenGL  Scientific visualization: VTK  Other toolkits exist which are a bit more geared towards game development  Plib  Fonts: Freetype & FTGL  Low level: OpenGL  Scientific visualization: VTK  Other toolkits exist which are a bit more geared towards game development  Plib  Fonts: Freetype & FTGL

16. GUI toolkits  GLUT - an older but still useful very lightweight toolkit for GL development  George wrote a C++ GLUT wrapper called Glutmaster  FLTK - my personal favorite; not the prettiest, but does everything you need  GLUT - an older but still useful very lightweight toolkit for GL development  George wrote a C++ GLUT wrapper called Glutmaster  FLTK - my personal favorite; not the prettiest, but does everything you need

17. GUI toolkits, cont.  wxWidgets - wraps native widget sets on each platform; therefore looks great, but fewer widgets than other toolkits  QT - the luxury swiss army approach to cross platform GUIs; expensive for proprietary devel, licensing issues for open source  wxWidgets - wraps native widget sets on each platform; therefore looks great, but fewer widgets than other toolkits  QT - the luxury swiss army approach to cross platform GUIs; expensive for proprietary devel, licensing issues for open source

18. Documentation  Doxygen is the gold standard  Easy to integrate with your web server to automatically generate fresh documentation each night  Doxygen is the gold standard  Easy to integrate with your web server to automatically generate fresh documentation each night

19. Bug tracking  May or may not be useful depending on the number of users/developers you have  First line of defense is a mailing list, telephone conferencing, or meetings  If that’s not adequate, try GNATS or another bug tracking program  May or may not be useful depending on the number of users/developers you have  First line of defense is a mailing list, telephone conferencing, or meetings  If that’s not adequate, try GNATS or another bug tracking program

20. Open source licensing  There are many options  Don’t assume they’re all the same  Popular licenses you’ll likely run across:  GPL  LGPL  BSD  There are many options  Don’t assume they’re all the same  Popular licenses you’ll likely run across:  GPL  LGPL  BSD

21. GPL  Possibly the most pervasive license in the Linux world  Often referred to as “viral”  Other licenses may be termed GPL- compatible  Derivative code must still be GPL’d  Possibly the most pervasive license in the Linux world  Often referred to as “viral”  Other licenses may be termed GPL- compatible  Derivative code must still be GPL’d

22. LGPL  Similar to the GPL, but more permissive  Your code can use LGPL code in library form without having to be released under the GPL  Common license for libraries (graphics, sound, etc.) as opposed to end-user programs  Similar to the GPL, but more permissive  Your code can use LGPL code in library form without having to be released under the GPL  Common license for libraries (graphics, sound, etc.) as opposed to end-user programs

23. BSD  A very permissive license that essentially requires only an acknowledgement and waiver of liability  Good for open source projects that will be used in close-sourced code  ITK and VTK are released under a BSD flavored license  A very permissive license that essentially requires only an acknowledgement and waiver of liability  Good for open source projects that will be used in close-sourced code  ITK and VTK are released under a BSD flavored license

24. Licensing take-home  If you choose to open-source your code, choose your license carefully  With the GPL in particular it can be easy to have your code “get away from you”  My opinion: the BSD license is the most academic friendly, others disagree  If you choose to open-source your code, choose your license carefully  With the GPL in particular it can be easy to have your code “get away from you”  My opinion: the BSD license is the most academic friendly, others disagree

25. What level to buy in at?  Solo project - CVS/SVN, Doxygen documentation  Small lab - perform manual build tests and fix problems via a mailing list, CVS/SVN web access  Large lab/several labs - add automated build testing, GNATS bug tracking  Solo project - CVS/SVN, Doxygen documentation  Small lab - perform manual build tests and fix problems via a mailing list, CVS/SVN web access  Large lab/several labs - add automated build testing, GNATS bug tracking

26. Unless you have a good reason, always…  Program with multiple OS’s in mind  Test on alternative OS’s if practical  Document, document, document  Store your code using revision control  There’s NEVER a good reason not to do this. NEVER EVER. You are a fool if you don’t use revision control. Get it?  Program with multiple OS’s in mind  Test on alternative OS’s if practical  Document, document, document  Store your code using revision control  There’s NEVER a good reason not to do this. NEVER EVER. You are a fool if you don’t use revision control. Get it?