|
|
| |
|
|
You are suppose to know how to write a Makefile
already. If you don't, you should learn it as soon as
possible because your Makefile must work in all
your programming assignment submissions. There are a few tutorials on
make on the web. Here are links to some of them.
I have not really read through these pages so I cannot
guarantee their correctness.
|
| |
|
Windows Makefiles
|
|
Please be aware that if you transfer a Makefile from a Windows
environment to a UNIX environment, chances are, it will not work.
The reason is that a line in a text file in Windows ends with "\r\n"
while a line in a text file in UNIX ends with just "\n". The extra
"\r" can confuse make on UNIX machines. But I'm sure you can
write a small program to fix that.
|
| |
|
Compiling Your Code
|
|
If you are writing your program in C, you should use gcc
as your compiler, rather than cc. Gcc supports
function prototypes and other ANSI extensions, which you should
use in your programs.
The option -Wall turns on most of the useful
gcc warnings.
Compiling with this option will find many simple mistakes in your programs.
On many platforms you also need to link the network and socket
libraries to your program.
|
| |
|
Requirements (Minimum)
|
|
Since grading of all programming assignments must be done on nunki.usc.edu
in the grading account (which you do not have access to)
or on a Ubuntu 14.04 or 16.04 machine running inside VMware/VirtualBox/VagrantBox,
it's imperative that you make sure that your code can be compiled and run on nunki.usc.edu and
your code doesn't depend on which account it's running on
or on a Ubuntu 14.04 or 16.04 machine running inside VMware/VirtualBox/VagrantBox.
Please understand that if your code runs perfectly on some other systems, we cannot give you any partial credit for that.
We will evaluate your submission by copying all the files you have
submitted into an empty directory in the grading account on nunki.usc.edu
or on a Ubuntu 14.04 or 16.04 machine running inside VMware/VirtualBox/VagrantBox
and then type the following command:
make
(If an individual programming assignment spec has more specific way of producing
executables, you must follow it.)
Minor variation (such as using gmake) is allowed, but you must
describe in details how to compile your code near the top of
your README file. Requiring a visual tool to compile your code
is not allowed.
If this does not produce the desired executable(s), you will
probably lose a lot of points.
You may lose quite a few points if the grader has to debug and
modify your Makefile in order to get your code to compile.
How many points you will lose depends on
how hard it is for the grader to get your Makefile to work.
You may even receive a score of zero if we cannot get your Makefile
to work.
Here are some additional requirements (sorry about redundancy
with the programming assignment specs):
- When the following command is invoked at the UNIX prompt:
make clean
all binary files created during compilation
(.o files, .gch files, executable files, etc.) must be removed.
- To compile your code, you must use either gcc (if your
program is written in C) or g++ (if your program is written in C++)
and you must use the version that's already installed on nunki.usc.edu
or on a Ubuntu 14.04 or 16.04 machine running inside VMware/VirtualBox/VagrantBox.
No other compilers will be permitted.
- You must use -Wall (or equivalent) in your Makefile
when you compile with gcc/g++ and you must eliminate
all compile-time warning messages.
By the way,
if you think you have a perfectly working Makefile
but when you run "make", you get an error message saying it
does not know how to make a target, it's probably because you
have created or modified your Makefile on a Windows machine
and what you have is a DOS/Windows text file, which is not
quite compatible with a Unix text file. In this case, you
can either use "gmake" or run "dos2unix"
to convert a DOS/Windows text file into a Unix text file.
When you compile, if you get warning messages saying that certain
.c or .h file has no newline at end of file,
then it's cause by the same problem (i.e., you have created these
files in Windows). Please run "dos2unix"
to convert such a DOS/Windows text file into a Unix text file.
|
| |
|
README
Requirements for Programming Assignments
|
|
A README file is the documentation of your submission.
The filename you must use for a README is "pa#-README.txt" where
"#" is the assignment number. You are expected to download
a README file template from the spec, edit it with a text editor by supplying
all the required information, and then include it with your submission.
Such a README file includes the following sections:
- A section called "BUILD & RUN" - This section contains instructions for creating the executable for your assignment.
Since the grader can only grade on nunki.usc.edu or on Ubuntu 14.04 or 16.04, you need to tell the
grader which system to use to grade your submission.
You are required to replace the first "(Comments?)" in this section with the environment to grade your submission.
The only permitted systems are "nunki.usc.edu", "VMware", "VirtualBox", or "VagrantBox".
You are required to replace the 2nd "(Comments?)" in this section with name of the OS to grade your submission.
The only permitted responses are "Solaris", "Ubntu 14.04", or "Ubuntu 16.04".
On Ubuntu, you may require additional packages to be installed into the OS so that your program can compile and run.
You are required to replace the 3rd "(Comments?)" in this section with a list of names of the packages your program depends on
(to be used in "sudo apt-get install PACKAGENAME") or "(none)" before grading can begin.
Only packages from the standard repository is permitted (i.e., you must not use something like a
"add-apt-repository" command to install packages from a non-standard repository).
You are required to replace the 4th "(Comments?)" in this section with the command the grader must type to compile your program.
If all the grader has to do is to type "make", you are still required to say so in this section.
- A section called "SELF-GRADING" - This section contains your assessment of your submission.
Each item in this section corresponds to an item in the grading guidelines.
You are required to replace every "?" in this section with a numeric value.
You are expected to run through the grading guidelines and give each item a grade.
- A section called "BUGS / TESTS TO SKIP" - If there is a test that you don't want the grader to run because
it may cause you to lose additional points elsewhere, please clearly state it in this section.
Please read the instructions there.
You are required to replace the "(Comments?)" in this section with either the word "none" or whatever appropriate information you want to provide.
- A section called "OTHER (Optional) - Not considered for grading" - This is just for you. The grader will not read this section.
|
| |
|
Additional
Hints
|
How do you make sure that make would work? It's actually
very simple.
- Create a Makefile first time you need to compile your code.
Don't wait till the last minute.
- If you do your development on Windows and expect your code to
just compile and run on nunki.usc.edu, you will soon find out
how unrealistic your assumption is. I would leave at least
2 days for porting for small programming assignments and 5 days for porting
large programming assignments.
- Write a rule in your Makefile to generate a submittable
file in the right format. Do this early! You can also think of
this as generating a backup copy of what you have done so far.
Copy the backup copy to another place in case you accidentically
erase all your files.
- Testing! Verify your submissions.
Create an empty directory on nunki.usc.edu
or on a Ubuntu 14.04 or 16.04 machine running inside VMware/VirtualBox/VagrantBox,
unpack your test submission, and type make in it!
If it doesn't work, fix it right away.
- Have a working copy ready for submission. When it's 2 hours away
from the deadline and your code is not completing working, you
should probably consider doing the following.
- Fix your code so that it compiles and runs.
- Create a submission from your working code and keep it as
a backup in case you can't fix your bugs when deadline comes.
- Repeat this as you fix more bugs.
|
| |
|
