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 project 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.

• a detailed tutorial from University of Hawaii
• just google it

Since I don't track these links, if they have moved, just google "makefile tutorial".
 

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.

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.

We will evaluate your submission by copying all the files you have submitted into an empty directory and then type the following command:

    make

(If an individual project 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 project specs):

• You are required to use separate compilation to compile your source code. You must divide your source code into separate source files in a logical way. Even if everything can fit in a single source file, you must force yourself to cut it up or you will lose a lot of points!

• You must not put the bulk of your code in header files! Header files are not where you are suppose to put your source code because you will lose the ability to debug your code.

• 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.

• You must use -Wall (or equivalent) in your Makefile when you compile with gcc 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.

A README file is the documentation of your submission. The filename you must use for a README is "x-README.txt" where "x" is an appropriate name for the assignment. 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. If all the grader has to do is to type "make", you are still required to say so in this section. Please note that minor variation on "make" is acceptable without penalty. Please read the instructions there. You are required to replace the "(Comments?)" in this section with the command the grader should type to create your executable.
• 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.

For kernel assignments, the README files are similar, although there are additional information you must provide. Please read the READE file template in the respective part of the spec carefully.

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 projects and 5 days for porting large projects.

• 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, 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.
  1. Fix your code so that it compiles and runs.

  2. Create a submission from your working code and keep it as a backup in case you can't fix your bugs when deadline comes.

  3. Repeat this as you fix more bugs.