Held: Tuesday, 22 April 2003
Today we consider some key tools for program management, include
separate compilation, make, and CVS.
- What did you think about
Sorting Out Sorting? (I see from
Erik's plan that his opinion has changed.)
- Using Multiple Source Files.
- Make and Makefiles.
- What do we care about when managing a program?
- That we can retrieve code we've accidentally deleted.
- That we can easily share our code with others.
- That the compiler can tell what needs to be done.
- Rather than putting all of our source code into one file, it is often
best to separate the different parts into different files.
- Fewer files to recompile upon change (yes, compilation was once
a slow process).
- Easier to give separate parts to different people.
- May make logical sense to separate the program into parts.
- Parts are easier to reuse.
- In C, you can stop compilation at the "object code" stage by including
-c in the command.
- For example,
gcc -c foo.c produces
- Once you have a lot of .o files, you link them together with
gcc -o program file1.o file2.o ... filen.o
- As you start developing more sophisticated programs, you'll spend a lot
of time trying to remember what needs to be done for different programs.
- For example, you may have a list of .o files that need to be put
together for an executable.
- Similarly, you may need to turn a debugging flag on or off for all
of your compilation.
- You may also have the problem of trying to remember what files you've
changed since your last build.
- Make and its makefiles help solve all of these problems.
- We'll take a quick look at my standard makefile and some you might
- How do you successfully share lots of files with lots of people?
- How do you deal with different people potentially updating the
- Traditionally with RCS, the revision control system
(at least in the Unix world).
- More recently, with CVS, the concurrent versioning system.
- What do you need to know about CVS?
- You can access CVS locally or over the Web.
- Once you've "checked out" a project, it remembers where it came from.
- A simple first CVS session
- Check out a project.
- Modify files.
- Confirm that your changes work.
cvs diff to compare your files to those in the repository
cvs commit to check in your changes
- A simple second CVS session
cvs update to incorporate changes your colleagues made.
- Modify files.
- Discover that you've made a new file to incorporate in the project.
cvs add to add it.
- Continue as before.
- To create a new project, use the following incredibly complex command
from within the top-level directory of the project.
cvs -d cvs-directory -m "comment" project vendor start
- directory is the Unix directory which you are adding to the
- vendor is the person who "owns" the project. I use
- What can you put under CVS control?
- Code files.
Tuesday, 7 January 2003 [Samuel A. Rebelsky]
- Created generic version to set up course.