Table of Contents
![[Warning]](warning.png) | Warning |
|---|---|
BuildServer support for C projects is somewhat experimental. |
Creating a C project to work with the BuildServer is very similar to creating a Java project. (See Chapter 12, Creating Java Projects.)
You will probably want to start by getting the sample C project included with the Marmoset distribution. This is also available in examples.jar.
One important difference between Java projects and C projects is that for C projects, the BuildServer extracts the student submission and test setup jarfile into the same directory. Essentially, the build directory and test files directory are the same. The student files are extracted first, and the instructor files (from the test setup jarfile) are extracted last. That way, student files cannot overwrite instructor files.
In C projects, each test is represented by an executable file
file that exercises the implementations with different inputs
and return an exit code. 0 means pass, anything non-zero means
fail. See the example C-project for samples of test executables.
Here is an example of a Python script that is used as a
test executable. The student's implementation executable is called
studentexecutable:
#!/usr/bin/env python
import commands
import sys
if commands.getoutput("./studentexecutable inputfile1 5") == "Hello World":
print "passed"
sys.exit(0)
print "failed"
sys.exit(1)
The test setup should contain the testing files excluding the files the student should implement. The example C project includes a Make file that creates this test setup by archiving all the appropriate files including the test.properties file.
The test setup should also include a Make file that will compile the student code and create test case executables. On the Build Server the test-setup is created using this make file (or what ever setting is specified in the test.properties file).
Then the test executables specified in test.properties are executed one at a time and the results of the tests are recorded
Note that in Java, it is impossible to create a file with Unix executable permissions set. Therefore, when the BuildServer extracts files, it cannot make them executable. Thus, your Makefile will need to change the permission on any files that need to be invoked, either later in the Makefile or in test cases. If your Makefile or test executables need to invoke shell scripts, perl scripts, and the like, then the Makefile will first need to change the permissions to make these files executable.
The canonical solution simply contains the correct implementation. It does NOT need a Make file or supporting files since the test setup will provide these files.
The Skeleton archive containing starter files for students should contain header files and any other supporting files students need. It should also contain public tests and perhaps a Makefile that students use to compile their projects. All these files except the implementation file will be overwritten by the versions in the test setup.
Student code is untrusted, and could do lots of nasty things. For example:
Killing the BuildServer process.
Reading secret instructor files, or overwriting them.
Opening network connections, creating fork() bombs, etc.
There is no satisfactory way to prevent this at present.
Student code cannot, however, access anything that's not physically on the BuildServer machine, such as the database containing grades and other people's submissions, or the submitServer that runs the web application front-end. Thus if students write malicious code, we'll have logs on the last message received from that BuildServer as well as a copy of the malicious submission itself. So it's very likely that we'll figure it out if someone is causing problems in this way.