ITK Lecture 12: Open Source & Cross Platform Software Development

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

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

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

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

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

6. CVS benefits • “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

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

9. Subversion benefits • 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)

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

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

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

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

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

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

18. Documentation • 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

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

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

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

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

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

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

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?