This week's lab simulates the the real-life workflow of a computer programmer starting on an unfamiliar project.
Whether working for a company or contributing to open-source projects, at some stage in your career you will end
up working with code written by somebody else. When this happens, you will work through the following steps:
Access the code (get it onto your computer)
Understand the code, at least at a high level. If you're lucky there will be a README to explain it.
Figure out what you need to change and how you will change it
Record your changes in such a way that they can be passed on to other users of the codebase.
Typically, we imagine that most computer programming work falls under step 3, because this is where the creativity,
problem solving and code-writing occurs. However, all four steps are critical for understanding and contributing to a project.
If you can learn the four steps, you will be prepared to work on any software project.
To illustrate this point, this week's lab uses unfamiliar languages (C and make) and an unfamiliar workflow (git).
Questions
Step 1: Access
Copy the repository from /lab/week11/casino.tar.gz to your mapped directory. Once there, extract it using tar:
tar -xvf casino.tar.gz
cd casino
Step 2: Understand
Work out how to build and run monty - the README file should help you out here. Once you build it, run
./monty and see what it does.
Use git log to look at the existing commits. These show what has been worked on in the project and can help you
understand what state the project is in.
git log
Step 3: Change
Before making changes, check out a new branch to keep your work separate from main.
git checkout -b lab11
Check you are on the correct branch using git status
Create a Makefile with a single target called build. This target should execute the same command you used when you
built monty back in step 2. This target should have montyhall.c as a dependency.
Note the tab (not spaces) indent before the gcc command. Makefiles are very finicky about tab indentation. Vim has been set up
in the lab docker image to use tab indents by default for Makefiles.
As you are working, you can use git diff at any time to see the changes you have made. Use git status
to see the repository status: what files have been changed, what branch you are on, etc
Step 4: Record
Before making a commit, we need to tell git who we are. Run the commands below to configure git with a username and email. These can
be whatever you want. If you are publishing a repository publically, it's a good idea to use a fake email address.
git add Makefile # tell git to track the Makefile and include its changes in the next commit
git status # check the status of the repo
git commit # this will open an editor so you can record an appropriate commit messsage, save and quit the editor when done
git status # check the status of the repo and see how it has changed
Note that we did not commit the binary file monty - this can be generated from the other files so we don't
need to track it in git.
Use git log to look at the list of commits. The most recent one should be your new commit.
Congratulations, you have just contributed to an unfamiliar project, using a new workflow and working with new languages!
Further exercises
These exercises give you some further practice with git and make.
Create a .gitignore file so that git ignores the compiled monty binary.
monty
Commit your changes, using an appropriate commit message.
Add a clean rule to your Makefile. This rule should remove any files produced by the build process
(in this case, just the compiled monty program).
Commit your changes, using an appropriate commit message.
Add another make rule called install which installs compiled binary.
Note: Installation on linux is as simple as copying the binary to an appropriate location (usually one on your PATH).
In this case, copy the binary to /usr/games.
