Transcript Open Source & Cross Platform Software Development

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
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
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
Revision control
 Allows many developers to change a
common code base simultaneously
 Revision control of ASCII text files is
easy; binary files are harder
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
CVS benefits
 “Reference” version control software many different client applications
 Does the job well enough to require
serious thought before replacing
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
Subversion
 A newer CVS alternative, core syntax is
identical
 Server configuration:
 Apache web server
 svnserve - custom server
 svnserve & ssh - custom server with
encryption layer
Subversion benefits
 More capable versioning core - directory
deletion a legal operation
 More flexible configuration options
 Fewer security issues
Subversion problems
 Fewer clients available
 Windows (Tortoise SVN)
 Mac (SVNx)
 Command line (most other Unixes)
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
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
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
DART, cont.
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
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
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
Documentation
 Doxygen is the gold standard
 Easy to integrate with your web server
to automatically generate fresh
documentation each night
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
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
GPL
 Possibly the most pervasive license in
the Linux world
 Often referred to as “viral”
 Other licenses may be termed GPLcompatible
 Derivative code must still be GPL’d
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
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
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
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
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?