系统编程代写 CITS2002 Systems Programming bake

Project 2018. See also: Project clarifications

Project Description – the program bake

In Lecture 12 the standard Unix utility make, frequently used to maintain programming projects through knowledge of the projects’ dependencies, was introduced. For this project we’ll develop a program named bake, providing a small, but useable, subset of make‘s facilities, with the addition that a project’s dependencies may include resources accessible over the Internet.Similar to make, our program bake will read the specification of a project’s dependencies from a line-oriented textfile. By default, bake will first attempt to open the file Bakefile or (if unsuccessful) the file bakefile from the current working directory. Sequences of characters on each line that are separated by one or more space or tab characters are termed words and are used to identify targets and dependencies (see later).The text lines within bake‘s specification file are of four forms –

1. lines beginning with a ‘#’ character are comment lines and may be ignored;
2. lines providing variable definitions which may be expanded within later lines of the file;
3. lines defining targets and optional dependencies used to determine if a target needs ‘rebuilding’; and
4. lines defining actions, immediately following target lines, providing shell commands to be executed to ‘rebuild’ each target. Note that action lines do not necessarily create or rebuild a (physical) file named after the target, and a target might never exist as a file.

Lines within the specification file that end with the ‘\’ character (actually, the last character before the line’s newline sequence) indicate that the followingline is a continuation of the current line, and should be appended to form a ‘combined’ line.

Variable definitions

Lines providing variable definitions are of the form:

NAME = VALUE

where zero-or-more whitespace characters (spaces and tabs) may appear before and after the ‘=’ character. If the pattern $(NAME), known as a variable expansion, appears anywhere on any following text line, the pattern $(NAME) is replaced at that point by the characters of VALUE.If a variable expansion requests a variable NAME that has not been previously defined in the file, then the value of NAME is sought from the bakeprocess’s environment. Thus the variable expansion $(HOME) might be expanded with the value /User/home/chris at that point. If no value of NAMEcan be found anywhere, the empty string is ‘inserted’ at the current point.As special cases, the variable expansions $(PID), $(PPID), $(PWD), and $(RAND) are replaced by the results of the function calls getpid(), getppid(),getcwd(), and rand() formatted as strings, respectively.Any line may have multiple variable expansions. Note that a variable expansion may occur at any point in the text file, including in the NAME and VALUE parts of a new variable definition line itself.A typical example is:

C99 = cc -std=c99 -Wall -pedantic -Werror
….
$(C99) -o try try.c

 

C99 functions and OS system-calls that will help you implement variable definitions – calloc(), realloc(), strdup(), getpid(), getppid(), getcwd(),rand(), and getenv().

Target lines

Lines defining a target are of the form:

targetname : [optional dependencies]

where zero-or-more whitespace characters (spaces and tabs) may appear before and after the ‘:’ character. The first targetname found in a file is the default target, and is the one to be rebuilt if no other targetname is provided on bake‘s command-line (see later).If the targetname represents a file in the current working directory, then the file’s modification date is used as the date of the target. Otherwise, the target is assumed to be created by the target’s actions, if they are successfully executed.Dependencies: Each target line may provide zero-or-more dependencies. If there are no dependencies, then the target requires rebuilding. There are three types of dependencies – ones that identify existing files on disk, ones that identify other targets, and ones that identify a web-based URL (a Uniform Resource Locator). If any dependency does not exist, or has been modified more recently that its target, then the target requires rebuilding (see Action lines).URL dependencies: if a dependency looks like an simple URL (it commences with the pattern file://, http://, or https://) it is assumed to define a URL to be requested to determine if the associated file exists and has been modified more recently that the current target.
bake must use the external utility curl to determine if the file (indicated by the URL) has been modified more recently than the current target. curl is usually installed on macOS or Linux machines, and is available from curl.haxx.se. Note that bake should not download the indicated file, just use curl‘s –head option to find the modification date. However, any target’s action may choose to explicitly download a file. It is an error if curl reports if a URL-based dependency is not found; it is not sought as a target.

C99 functions and OS system-calls that will help you implement target lines – calloc(), realloc(), strdup(), stat(), fork(), execl(), wait(), fopen(),fgets(), fclose(), mktime(), gettimeofday(), and strptime().

Action lines

Lines defining actions must immediately follow a target line, or another action line. We say that the sequence of one-or-more action lines are associated with a given target. Action lines must begin with a tab-character (providing a visual indentation). They are of the form:

\t[optional modifier] shell-command-sequence

If a target requires ‘rebuilding’, then each of its associated actions are passed, in turn, to the external command defined by the value of SHELL from the bake process’s environment. In the absence of an environment variable named SHELL, the default value /bin/bash is to be used. Each action’s command sequence is to be executed by the external program provided by the value of SHELL by passing the command sequence to the shell’s -ccommand-line option. Note that none of the characters forming the shell-command-sequence are interpreted by bake.For example, if a shell-command-sequence rm -f tempfile needs be executed, then bake may invoke and wait for the command
/bin/bash -c “rm -f tempfile”.Each associated action is executed in turn (top-to-bottom) until either all actions are executed or until one of them terminates with failure (with a non-zero exit status). If all associated actions execute successfully, then the target is considered ‘rebuilt’ (even if it wasn’t actually created or modified).Action line modifiers: A modifier is a single character that appears between an action’s leading tab character and its shell-command-sequence:’@’ – By default bake prints each command sequence to stdout just before it is executed. If the ‘@’ modifier appears, the command sequence should not be printed.’-‘ – By default bake uses the exit status of an action to determine if following actions should be executed. If the ‘-‘ modifier appears, the exit status of an action is always considered to be a success (even if the command sequence actually failed).

C99 functions and OS system-calls that will help you implement action lines – getenv(), calloc(), realloc(), strdup(), fork(), execl(), and wait().

Invocation and command-line options

bake is to be invoked with:

bake  [command-line-options]  [targetname]

The default execution of bake may be modified through a small number of command-line options. If any option is provided multiple times, only the last occurence of the option is used. If the optional targetname is present, then it is the target to be (possibly) rebuilt instead of the default (first) target.The options are:-C directoryname : before commencing execution, bake is to change directory to the indicated directory.-f filename : instead of reading its specification from the default Bakefile or bakefile, bake reads its specification from the indicated file.-i : ignore the unsuccessful termination of actions; continue executing a target’s actions even if any fail.-n : print (to stdout) each shell-command-sequence before it is to be executed, but do not actually execute the commands. Assume that each shell-command-sequence executes successfully. This option enables bake to simply report what it would do, without doing it.-p : after reading in the specification file, print its information (from bake’s internal representation) to stdout with all variable expansions performed. Then simply exit with success.-s : execute silently, do not print each shell-command-sequence before it is executed.

C99 functions and OS system-calls that will help you implement command-line options getopt(), chdir(), and exit().

Assessment

This project is worth 30% of your final mark for CITS2002. It will be marked out of 60. The project may be completed individually or in teams of two(but not teams of three). You are strongly encouraged to work with someone else – this will enable you to discuss your initial design, and to assist each other to develop and debug your joint solution. Do not attempt to split the project into two equal parts, and then plan to meet near the deadline to join your parts together.40 of the possible 60 marks will come from the correctness of your solution. The remaining 20 marks will come from your programming style, including your use of meaningful comments, well chosen identifier names, appropriate choice of basic data-structures and data-types, appropriate choice of control-flow constructs, and isolation of distinct responsibilities in separate source files.During the marking, attention will obviously be given to the correctness of your solution. However, a correct and efficient solution should not be considered as the perfect, nor necessarily desirable, form of solution. Preference will be given to well presented, well documented solutions that use the appropriate features of the language to complete tasks in an easy to understand and easy to follow manner. That is, do not expect to receive full marks for your project simply because it works correctly. Remember, a computer program should not only convey a message to the computer, but also to other human programmers.Your project will be marked on the computers in CSSE Lab 2.03, using the macOS environment. No allowance will be made for a program that “works at home” but not on CSSE Lab 2.03 computers, so be sure that your code compiles and executes correctly on these machines before you submit it.

Submission requirements

1. The deadline for the project is 12noon Friday 26th October (end of week 12).
2. Your submission will be compiled, run, and examined using the macOS platform on computers in CSSE Lab 2.03. Your submission must work as expected on this platform. While you may develop your project on other computers, excuses such as “it worked at home, just not in the lab!”  will not be accepted.
3. Your submission’s C99 source files should each begin with the C99 block comment:

   /* CITS2002 Project 2018 Name(s): student-name1 (, student-name2) Student number(s): student-number-1 (, student-number-2) */

   If working as a team, only one team member should make the team’s submission.

4. You must submit your project electronically using cssubmit. You should submit all C99 source-code (*.c) and header (*.h) files and a Makefileand a Bakefile that specify the steps required to compile and link your project. You can submit multiple files in one submission by first archiving them with zip or tar. You do not need to submit any additional testing scripts or files that you used while developing your project. The cssubmit facility will give you a receipt of your submission. You should print and retain this receipt in case of any dispute. Note also that the cssubmit facility does not archive submissions and will simply overwrite any previous submission with your latest submission.
5. This project is subject to UWA’s Policy on Assessment – particularly §10.2 Principles of submission and penalty for late submission. In accordance with this policy, you may discuss with other students the general principles required to understand this project, but the work you submit must be the result of your own efforts. All projects will be compared using software that detects significant similarities between source code files. Students suspected of plagiarism will be interviewed and will be required to demonstrate their full understanding of their project submission.