CSC195, Class 46: Program Management

Overview:
* Introduction: What do we want?
* Building Programs from Multiple Source Files
* Makefiles
* CVS

Notes:
* Upcoming presentation in 151 (2:15 on Monday)
* New homework (although Sam forgot to finish writing it
  because he had too many appointments today).
* What did you think about "Sorting Out Sorting"?
* Where are Erik and Daren?
* Come hear Devin talk about 3D graphics and Reese talk
  about data mining next Wednesday at 4:30 pm.

What are some issues you care about when you start to
build large projects?
* Communication between group members
* Don't let egos get out of hand (no SamRs allowed)
* Specify stuff carefully
* Try to keep code compatible and consistent
  + Coding style
  + Use the specifications (implement what you documented;
    call what you documented; don't change the specifications)
* Explain internals
* Break up your program into logical components
* Provide an easy way to share your files with your colleagues
* Share nicely (not too much, not too little)
* Document how the pieces go together

Breaking big C programs into lots of little files

How
* Declare shared stuff (types, variables, procedures) in 
  header files
* Create a .c file for each part
  foo.c bar.c baz.c runthewholeshebang.c
* Compile each .c file separately to a .o file
  .c : C code
  .o : object code
  cc -c foo.c
  cc -c bar.c
  cc -c baz.c
  cc -c runthewholeshebang.c
* Shove it all together ("link", the original "compile")
  cc -o runit foo.o bar.o baz.o runthewholeshebang.o

Why?
* Might be easier to debug.
  + Compiler errors limited to a file at a time.
  + You can write small test programs for each file.
  cc -o testfoo foo.o footest.o
  testfoo
* Probably easier to understand each section in isoloation
* Harder/Easier to find one procedure
* Faster recompilationa
  You only need to recompile the file or files you've updated,
  not all of your code.
  + Minor issue for the size of programs we currently write.
  + Serious problem for large programs
  + Was once a serious problem for our programs

Eventually it gets hard to keep track of what goes with what.

make remembers things for you:
* What needs to be recompiled
* What goes with what
* What flags are set
* ...

Makefile
-----
CFLAGS=-g
runit: foo.o bar.o baz.o runthewholeshebang.o
	$(CC) -o runit foo.o bar.o baz.o runthewholeshebang.o

bar.o: ffff.h
-----

How to share with your friends
* And keep track of old versions, because you know you will
  eventually delete a procedure you'll need
* RCS: Revision control system
  Keeps track of every version of your source code
  Does so efficiently
WHOAAAA FLASHBACK
* In more recent history, people realized things like RCS
  were good for sharing code
  CVS: Concurrent versioning system
    A wrapper for rcs
    Supports concurrent changes to the same file
    Assumes large user base
    Assumes (or supports) web based updates
    More than Linux/Unix

The basics:

  There  are centralized "repositories" where one or more
    "projects" go.
  Each project can have its own space

Joining a local project
  cvs -d REPOSITORY checkout PROJECT

  cvs -d /home/rebelsky/CVSTEST checkout Test

  Edit any intersting files

  Confirm that the changes work

  Find out what changes you made with
    cvs diff

  Check in your changes with
    cvs commit

CVS also encourages you to log what you do (which helps your
groupmates)