Copyright © 2004 Momchil A. Velikov
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in Appendix B, GNU Free Documentation License.
Table of Contents
List of Examples
The mk utility automatically determines, which pieces of a program need to be recompiled and issues commands to recompile them. It is similar in purpose to the popular make, scons and jam tools. The mk utility works by reading one or more mkfiles, usually named MK. The mkfiles construct a database of targets, their prerequisites and the commands, used to update the targets, when one or more prerequisite changes.
[TBD: Explain what the following items actually mean.]
The mk utility is distributed under the terms of the GNU General Public License, version 2. A verbatim copy if the license is given in Appendix A, GNU General Public License.
Table of Contents
In this section we will discuss a simple mkfile, which describes how to compile and link the venarable "Hello, World!" program.
We will have one source file, hello.c, with the following content:
$ cat hello.c
#include <stdio.h>
int
main ()
{
puts ("Hello, World!");
return 0;
}
Here's a straightforward mkfile, which describes how the program hello is built from the source file hello.c
$ cat MK
mk.make_program ('hello', srcs = ['hello.c'])
The mkfile instructs the tool to make an executable program via the function mk.make_program. The first parameter of the function is the name of the program and the second is the list of the sources to the program. It can't be any simpler, can it ?
Now run the mk to build the program.
$ mk
Surprisingly, nothing happens. The reason is simple - we haven't told mk what to build. Let's try again:
$ mk ./hello
cc -c -g -o hello.o hello.c
cc -g -o hello hello.o
$ ./hello
Hello, World!
This time everything worked as expected, we have successfully built the hello program and were able to execute it. Note, however, how did we tell mk what to build - using ./hello instead of simply hello. The difference and the need is explained in detail in the section called “Target specification”, for now it's sufficient to say that hello is taken as a literal name, whereas ./hello is replaced with the full path name of the target.
Just like we are able to build the project, we should be able to clean it too. Fortunately mk can do this for us, by determining what should be cleaned, following the obvious rule - "Clean everything you can rebuild" or put it the other way, "Do not touch anything you CAN'T rebuild". The mk command line option for cleaning is -c (or --clean) and similarly to building targets, we need to specify what to clean (ignore the MK.cache file for now):
$ ls
MK MK.cache hello hello.c hello.o
$ mk -c ./hello
$ ls
MK MK.cache hello.c
Explicitly naming the targets on the command line can become tedious and, naturally, with mk we can do better. With no targets given on the command line, the mk command defaults to building the all target. This is a phony target, one that is not really a name of a file, but whose sole purpose is to provide a name to a group of targets. This grouping is achieved by making our targets prerequisites for the phony one. Here's how:
$ cat MK
hello = mk.make_program ('hello', srcs = ['hello.c'])
mk.env.all.depends (hello)
$ mk
cc -c -g -o hello.o hello.c
cc -g -o hello hello.o
$ ls
MK MK.cache hello hello.c hello.o
$ mk -c
$ ls
MK MK.cache hello.c
What did we do here? The function mk.make_program has a return value - a Python object [1], which represents our program. The variable mk.env.all is the object, which stands for the built-in all target[2]. By invoking the method depends we set the hello program as a prerequisite for the all target, thus whenever we build or clean all we perform the corresponding operation on hello too.
Let's add another source file to our project, putting the key functionality of printing "Hello, World!" in a separate function:
$ cat hello-proc.c
#include <stdio.h>
void
print_hello ()
{
puts ("Hello, World!");
}
$ cat hello.c
extern void print_hello ();
int
main ()
{
print_hello ();
return 0;
}
$
As we have already learned, we can add the new file to the project by simply listing it along with the hello.c name in the srcs parameter to mk.make_program as follows:
hello = mk.make_program ('hello', srcs = ['hello.c', 'hello-proc.c'])
An alternative way is to create a source object for the new source file:
hello_proc_c = mk.make_source ('hello-proc.c')
hello = mk.make_program ('hello', srcs = ['hello.c', hello_proc_c])
As we can see, we can mix strings and objects in the srcs parameter of mk.make_program.
Yet another way to achieve our goal of adding more files to the project is to compile the source file and add the resulting object file object as a prerequisite to the hello program target using the objs parameter.
hello_proc_o = mk.compile_source ('hello-proc.c')
hello = mk.make_program ('hello', srcs = ['hello.c'], objs = [hello_proc_o])
We will conclude the section by adding yet another source file and using yet another way to create objects and specify dependency relations, using the function mk.make_object. The new source file is called goodbye-proc.c and contains the print_goodbye function. Accordingly, we modify the main to call the new function.
$ cat goodbye-proc.c
#include <stdio.h>
void
print_goodbye ()
{
puts ("Goodbye, World!");
}
$ cat hello.c
extern void print_hello ();
extern void print_goodbye ();
int
main ()
{
print_hello ();
print_goodbye ();
return 0;
}
$ cat MK
hello_proc_o = mk.compile_source ('hello-proc.c')
goodbye_proc_o = mk.make_object ('goodbye-proc.o')
hello = mk.make_program ('hello', srcs = ['hello.c'],
objs = [hello_proc_o, goodbye_proc_o])
mk.env.all.depends (hello)
There are many more ways to create various source, object file, library, etc instances, which ways are specified in the section called “Factory functions”. Keep in mind that in all of the above cases, we actually ended up with the same set of objects [3], the only difference being in which objects we specified explicitly and which objects were created for us by mk.
Since the number of the source files started to grow, it's a good idea to reorganize our project a bit. Let's put the sources hello-proc.c and goodbye-proc.c in the subdirectory libhello and the main program source hello.c in the subdirectory src:
$ mkdir libhello
$ mv goodbye-proc.c hello-proc.c libhello/
$ mkdir src
$ mv hello.c src/
$ mk
Source file ``hello-proc.c'' cannot be located
The mk program is no longer able to find our files. We can fix the situation in several ways:
$ cat MK
hello_proc_o = mk.compile_source ('libhello/hello-proc.c')
goodbye_proc_o = mk.make_object ('libhello/goodbye-proc.o')
hello = mk.make_program ('hello', srcs = ['src/hello.c'],
objs = [hello_proc_o, goodbye_proc_o])
mk.env.all.depends (hello)
$ mk
cc -c -g -o libhello/hello-proc.o libhello/hello-proc.c
cc -c -g -o libhello/goodbye-proc.o libhello/goodbye-proc.c
cc -c -g -o src/hello.o src/hello.c
cc -g -o hello src/hello.o libhello/hello-proc.o libhello/goodbye-proc.o
$ cat MK
mk.env.source_path = mk.make_match_list ({r'\.c$' : ['libhello', 'src']})
hello_proc_o = mk.compile_source ('hello-proc.c')
goodbye_proc_o = mk.make_object ('goodbye-proc.o')
hello = mk.make_program ('hello', srcs = ['hello.c'],
objs = [hello_proc_o, goodbye_proc_o])
mk.env.all.depends (hello)
$ mk
cc -c -g -o libhello/hello-proc.o libhello/hello-proc.c
cc -c -g -o goodbye-proc.o libhello/goodbye-proc.c
cc -c -g -o src/hello.o src/hello.c
cc -g -o hello src/hello.o libhello/hello-proc.o goodbye-proc.o
$ ls
MK MK.cache goodbye-proc.o hello libhello src
The function mk.make_match_list [4] takes as a parameter a dictionary, in which keys are regular expressions and the values are lists of directory names. Source files, whose name matches the regular expression, are searched in the corresponding directories. The mk searches for the source files in the paths specified by the global variable mk.env.source_path. Note, however, that the object file goodbye-proc.o is still created in the current directory, since we specified it that way.
We choose the first method, explicitly naming the parent directory for each target.
Next, instead of linking with the object files, we create a static library and link to it. The library is created with the function mk.make_static_lib as follows:
libhello_a = mk.make_static_lib ('libhello/libhello.a',
srcs = ['hello-proc.c', 'goodbye-proc.c'])
and we link to the library, by passing it to the mk.make_program via the libs parameter:
hello = mk.make_program ('hello', srcs = ['hello.c'], libs = [libhello_a])
Note that we no longer need the variables hello_proc_o and goodbye_proc_o (which were put there for illustrative purposes anyway), so we can simply delete them, ending up with the following mkfile:
$ cat MK
libhello_a = mk.make_static_lib ('libhello/libhello.a',
srcs = ['libhello/hello-proc.c',
'libhello/goodbye-proc.c'])
hello = mk.make_program ('hello', srcs = ['src/hello.c'], libs = [libhello_a])
mk.env.all.depends (hello)
$ mk
cc -c -g -o libhello/hello-proc.o libhello/hello-proc.c
cc -c -g -o libhello/goodbye-proc.o libhello/goodbye-proc.c
cc -c -g -o src/hello.o src/hello.c
ar ruv libhello/libhello.a libhello/hello-proc.o libhello/goodbye-proc.o
ar: creating libhello/libhello.a
a - libhello/hello-proc.o
a - libhello/goodbye-proc.o
cc -g -o hello src/hello.o -Llibhello -lhello
Our mkfile contains build instructions for both a library and a program. With several such libraries or programs a single mkfile would become too unwieldy. We will separate the build instructions in the subdirectories we already have and let the top mkfile process the sub-mkfile instructions.
The subdirectory mkfiles look as follows:
$ cat libhello/MK
libhello_a = mk.make_static_lib ('libhello.a',
srcs = ['hello-proc.c', 'goodbye-proc.c'])
$ cat src/MK
hello = mk.make_program ('hello', srcs = ['hello.c'], libs = [libhello_a])
mk.env.all.depends (hello)
Note that we have removed the parent directories from the target names. The reason is that non-absolute pathnames are taken relative to the current source or build directory.
The subdirectory mkfiles are processed by the function mk.subdirs. This function takes a single parameter - a list of subdirectory names. Thus, the top level mkfile becomes simply:
$ cat MK
mk.subdirs (['libhello', 'src'])
and we can see that everything works as expected:
$ mk
cc -c -g -o libhello/hello-proc.o libhello/hello-proc.c
cc -c -g -o libhello/goodbye-proc.o libhello/goodbye-proc.c
cc -c -g -o src/hello.o src/hello.c
ar ruv libhello/libhello.a libhello/hello-proc.o libhello/goodbye-proc.o
ar: creating libhello/libhello.a
a - libhello/hello-proc.o
a - libhello/goodbye-proc.o
cc -g -o src/hello src/hello.o -Llibhello -lhello
We should immediately point out that what we have now are not recursive mkfiles. All our mkfiles work towards creating a single database of targets and prerequisites. We call this global view of all dependencies and its immensive utility will become obvious when we discuss building from within subdirectories.
Note, that in our case, the order of the directories in the parameter to mk.subdirs matters. In the src/MK mkfile we refer to the variable libhello_a, which should already by assigned to, thus it is important that libhello goes before src.
Following the rule “Do only one thing and do it well” we decide to create not one, but two programs - one outputting Hello, World! and another, outputting Goodbye, World!. The new program's source goes to src/goodbye.c and we modify src/hello.c accordingly. As usual for the libraries, we add a header file libhello/hello.h defining the public interface of the library, thus obtaining:
$ cat libhello/hello.h
#ifndef libhello_hello_h
#define libhello_hello_h 1
extern void print_hello ();
extern void print_goodbye ();
#endif /* libhello_hello_h */
$ cat src/hello.c
#include "libhello/hello.h"
int
main ()
{
print_hello ();
return 0;
}
$ cat src/goodbye.c
#include "libhello/hello.h"
int
main ()
{
print_goodbye ();
return 0;
}
Since both the hello and goodbye programs are built in a very similar way, we can take advantage of the fact that our mkfiles are fully fledged Python sources and write src/MK thusly (cool, eh?):
$ cat src/MK
programs = ['hello', 'goodbye']
for prog in [mk.make_program (x, srcs = [x + '.c'], libs = [libhello_a])
for x in programs]:
mk.env.all.depends (prog)
Unfortunately, if we attempt to build now, the compiler will fail for being unable to find the header file. We need to modify the way the source files are compiled.
Each project target has an associated command object - an object, which holds all the options, switches, settings, etc. neccessary to execute the command, which updates the target. The command objects need not be unique, in fact, all the C source files in our project were compiled using the same object - the default C compiler object, referenced via the global variable mk.env.cc[2].
In order to solve our problem, we should add the top level source directory to the include search path of the compiler. The top level source directory is held in the global variable mk.env.top_srcdir and we can modify the default include file search path via the method includes of the default C compiler, mk.env.cc:
$ cat MK
mk.env.cc.include ([mk.env.top_srcdir])
mk.subdirs (['libhello', 'src'])
$ mk
cc -c -g -I../step6 -o libhello/hello-proc.o libhello/hello-proc.c
cc -c -g -I../step6 -o libhello/goodbye-proc.o libhello/goodbye-proc.c
cc -c -g -I../step6 -o src/hello.o src/hello.c
cc -c -g -I../step6 -o src/goodbye.o src/goodbye.c
ar ruv libhello/libhello.a libhello/hello-proc.o libhello/goodbye-proc.o
ar: creating libhello/libhello.a
a - libhello/hello-proc.o
a - libhello/goodbye-proc.o
cc -g -o src/hello src/hello.o -Llibhello -lhello
cc -g -o src/goodbye src/goodbye.o -Llibhello -lhello
It is worth noting, that we are completely unaware of the command line syntax of the concrete compiler tool. This knowledge is encapsulated in the compiler object itself, thus our mkfile is portable across different compilers.
Since we modified the default (and only) C compiler object, the include search path switch is passed unnecessarily when building the library objects too[5]. If this is considered undesirable, we should create a new compiler object, modify only it by the means of the includes method and specify that the build of the hello.o and goodbye.o object files should use that compiler object. Probably the easiest way to obtain a new compiler object is to copy an existing one, via the Python function copy.deepcopy. We can use either one of the mk.make_object or mk.compile_source functions to assign the new compiler object the task of building the object files by using the named parameter build[6]. Thus the src/MK file becomes:
$ cat src/MK
import copy
cc = copy.deepcopy (mk.env.cc)
cc.include ([mk.env.top_srcdir])
programs = ['hello', 'goodbye']
for name in programs:
obj = mk.compile_source (name + '.c', build = cc.compile)
prog = mk.make_program (name, objs = [obj], libs = [libhello_a])
mk.env.all.depends (prog)
and we remove the unnecessary include path setting in the top level mkile, so it becomes simply:
$ cat MK
mk.subdirs (['libhello', 'src'])
And we will rebuild the project to make sure everything works as expected:
$ mk -c
$ mk
cc -c -g -o libhello/hello-proc.o libhello/hello-proc.c
cc -c -g -o libhello/goodbye-proc.o libhello/goodbye-proc.c
cc -c -g -I../step6 -o src/hello.o src/hello.c
cc -c -g -I../step6 -o src/goodbye.o src/goodbye.c
ar ruv libhello/libhello.a libhello/hello-proc.o libhello/goodbye-proc.o
ar: creating libhello/libhello.a
a - libhello/hello-proc.o
a - libhello/goodbye-proc.o
cc -g -o src/hello src/hello.o -Llibhello -lhello
cc -g -o src/goodbye src/goodbye.o -Llibhello -lhello
Having a header file, we would like to be able to recompile the sources and rebuild the targets, which are affected by changes to it, i.e:
$ touch libhello/hello.h
$ mk
cc -c -g -I../step6 -o src/hello.o src/hello.c
cc -c -g -I../step6 -o src/goodbye.o src/goodbye.c
cc -g -o src/hello src/hello.o -Llibhello -lhello
cc -g -o src/goodbye src/goodbye.o -Llibhello -lhello
As we can see, mk solves this problem by itself, relieving us from the need to explicitly specify the header file dependencies. The mk scans the source files for preprocessor include directives. It uses the include file search path to find the header files and automatically makes them prerequisites for the target object file. Such a potentially time consuming operation is, of course, not performed on each build, but instead the implicit dependencies are stored (among other things) in a cache file - MK.cache. MK will recompute the implicit dependencies only when the corresponding source file changes. For all the other source files it will use the information in the cache file.
The generation of the implicit dependencies is customizable on a tool level. The generic C compiler (mk.tools.cc) uses a source file scan for preprocessor directives, whereas the GNU C compiler tool (mk.tools.gcc) uses the built-in GCC ability to automatically derive prerequisite header files[7].
A novel and, as of this writing, an unique feature of mk is its ability to support wide range of source and build directory dispositions with a single set of mkfiles, as well as its ability to perform builds from anywhere within the build tree, thus truely having a global view of all the dependencies.
In this configuration the source and the build trees are completely separate[8]. This configuration is achieved in the following ways:
from within the designated build directory, we execute the mk command, using the -f option to point to the top level mkfile. The parent directory of the mkfile is taken to be the top level source directory.
$ mkdir build $ cd build/ $ mk -f ../MK cc -c -g -o libhello/hello-proc.o ../libhello/hello-proc.c cc -c -g -o libhello/goodbye-proc.o ../libhello/goodbye-proc.c cc -c -g -I../../step6 -o src/hello.o ../src/hello.c cc -c -g -I../../step6 -o src/goodbye.o ../src/goodbye.c ar ruv libhello/libhello.a libhello/hello-proc.o libhello/goodbye-proc.o ar: creating libhello/libhello.a a - libhello/hello-proc.o a - libhello/goodbye-proc.o cc -g -o src/hello src/hello.o -Llibhello -lhello cc -g -o src/goodbye src/goodbye.o -Llibhello -lhello $ cd ..
from the top level source directory, we execute the mk command, using the -o option to refer to the top level build directory. The current working directory should contain the top level mkfile and is taken to be the top level source directory:
$ mk -o build2 cc -c -g -o build2/libhello/hello-proc.o libhello/hello-proc.c cc -c -g -o build2/libhello/goodbye-proc.o libhello/goodbye-proc.c cc -c -g -I../step6 -o build2/src/hello.o src/hello.c cc -c -g -I../step6 -o build2/src/goodbye.o src/goodbye.c ar ruv build2/libhello/libhello.a build2/libhello/hello-proc.o build2/libhello/goodbye-proc.o ar: creating build2/libhello/libhello.a a - build2/libhello/hello-proc.o a - build2/libhello/goodbye-proc.o cc -g -o build2/src/hello build2/src/hello.o -Lbuild2/libhello -lhello cc -g -o build2/src/goodbye build2/src/goodbye.o -Lbuild2/libhello -lhello
using both the -o and -f options
In this configuration we have multiple, identically named subdirectories of each source directory, which subdirectories contain the built targets. The subdirectories name is given with the -s option[9]:
$ mk -s debug
cc -c -g -o libhello/debug/hello-proc.o libhello/hello-proc.c
cc -c -g -o libhello/debug/goodbye-proc.o libhello/goodbye-proc.c
cc -c -g -I../step6 -o src/debug/hello.o src/hello.c
cc -c -g -I../step6 -o src/debug/goodbye.o src/goodbye.c
ar ruv libhello/debug/libhello.a libhello/debug/hello-proc.o libhello/debug/goodbye-proc.o
ar: creating libhello/debug/libhello.a
a - libhello/debug/hello-proc.o
a - libhello/debug/goodbye-proc.o
cc -g -o src/debug/hello src/debug/hello.o -Llibhello/debug -lhello
cc -g -o src/debug/goodbye src/debug/goodbye.o -Llibhello/debug -lhello
This configuration is a combination of the above two, where several trees, each named via the -s option, are contained within a single build “supertree”.
$ mk -o build -s release
cc -c -g -o build/libhello/release/hello-proc.o libhello/hello-proc.c
cc -c -g -o build/libhello/release/goodbye-proc.o libhello/goodbye-proc.c
cc -c -g -I../step6 -o build/src/release/hello.o src/hello.c
cc -c -g -I../step6 -o build/src/release/goodbye.o src/goodbye.c
ar ruv build/libhello/release/libhello.a build/libhello/release/hello-proc.o build/libhello/release/goodbye-proc.o
ar: creating build/libhello/release/libhello.a
a - build/libhello/release/hello-proc.o
a - build/libhello/release/goodbye-proc.o
cc -g -o build/src/release/hello build/src/release/hello.o -Lbuild/libhello/release -lhello
cc -g -o build/src/release/goodbye build/src/release/goodbye.o -Lbuild/libhello/release -lhello
To summarize, the top level build and source directories default to the current working directory. The -o options changes the default build directory, the -f option changes the default source directory and the -s option appends an additional pathname component to each build directory.
Once we have initiated a build, mk writes a cache file to the top level build directory. The cache file contains all of the above information - the build directory, the source directory and the output subdirectories name. This is a key to another unique feature of mk - the ability to build projects from anywhere within the build tree. Upon startup, mk searches for a cache file in the top level build directory, or, if no build directory specified, in the current working directory and up. Then the parent directory of the cache file becomes the top level build directory and the top level source directory and output subdirectories name are recovered from the information in the cache file.
$ touch src/hello.c
$ cd build/src/
$ mk -s release
cc -c -g -I../../../step6 -o release/hello.o ../../src/hello.c
cc -g -o release/hello release/hello.o -L../libhello/release -lhello
In the section we'll create a simple double-precision postfix (a.k.a. “reverse polish notation”) calculator, using the example sources from the GNU Bison manual. The source files are as follows:
the main program file, main.c.
#include <stdio.h>
int
main (void)
{
return yyparse ();
}
/* Called by yyparse on error. */
void
yyerror (char const *s)
{
printf ("%s\n", s);
}
the scanner (or lexical analyzer), rpnlex.c.
#include <stdio.h>
#include <ctype.h>
#include "rpncalc.h"
/* The lexical analyzer returns a double floating point number on the
stack and the token NUM, or the numeric code of the character read
if not a number. It skips all blanks and tabs, and returns 0 for
end-of-input. */
int
yylex (void)
{
int c;
/* Skip white space. */
while ((c = getchar ()) == ' ' || c == '\t')
;
/* Process numbers. */
if (c == '.' || isdigit (c))
{
ungetc (c, stdin);
scanf ("%lf", &yylval);
return NUM;
}
/* Return end-of-input. */
if (c == EOF)
return 0;
/* Return a single char. */
return c;
}
and the Bison grammar file, rpncalc.y
%{
#define YYSTYPE double
#include <math.h>
int yylex (void);
void yyerror (char const *);
%}
%token NUM
%% /* Grammar rules and actions follow. */
input: /* empty */
| input line
;
line: '\n'
| exp '\n' { printf ("\t%.10g\n", $1); }
;
exp: NUM { $$ = $1; }
| exp exp '+' { $$ = $1 + $2; }
| exp exp '-' { $$ = $1 - $2; }
| exp exp '*' { $$ = $1 * $2; }
| exp exp '/' { $$ = $1 / $2; }
/* Exponentiation */
| exp exp '^' { $$ = pow ($1, $2); }
/* Unary minus */
| exp 'n' { $$ = -$1; }
;
%%
In mk, Bison parsers are created with the function mk.make_parser. The function takes as a first parameter the parser name and, optionally, as a second parameter the grammar file name. Since the output of the bison consists of two files, the return value is a tuple with first element being the C source file of the parser and the second element being a header file with token definitions. The names of the parser source and the parser header are set to the value of the parser name with suffix .c or .h, respectively. However, unlike the case with other mk generated filenames, the parser source and header files are generated in the current source directory, unless the parser name parameter is a full pathname.
Here's the initial version of our mkfile, building only the objects for the moment:
rpncalc_c, rpncalc_h = mk.make_parser ('rpncalc')
mk.env.all.depends (mk.compile_sources (['main.c', 'rpnlex.c', rpncalc_c]))
However, when we attempt to build the project, we immediately get a problem:
$ mk
cc -c -g -o rpnlex.o rpnlex.c
rpnlex.c:4:21: rpncalc.h: No such file or directory
...
The file rpncalc.h is supposed to be generated by bison, but for some reason bison didn't even run. Explanation is simple - mk doesn't know it has to build rpncalc.h, because rpncalc.h is not a prerequisite to any target. How about automatic dependencies ? Unfortunately, the mk support for automatic dependencies generation is designed not to complain about missing dependencies, because it cannot in general decide whether a file is generated or there's insufficient information for finding it[10]. While it is possible in principle to keep building the project until the set of generated files (and thus the set of automatic dependencies) stabilizes, a design decision was made to explicitly specify such dependencies instead, like this:
rpncalc_c, rpncalc_h = mk.make_parser ('rpncalc')
rpnlex_o = mk.compile_source ('rpnlex.c')
mk.depends (rpnlex_o, rpncalc_h)
mk.env.all.depends (mk.compile_sources (['main.c', 'rpnlex.c', rpncalc_c]))
And we can build the project and see everything works fine:
$ mk
bison -d -o rpncalc.c rpncalc.y
cc -c -g -o main.o main.c
cc -c -g -o rpncalc.o rpncalc.c
cc -c -g -o rpnlex.o rpnlex.c
However, if we attempt to clean the project, we get another nasty “surprise” - the generated files are not removed:
$ mk -c
$ ls
MK MK.cache main.c rpncalc.c rpncalc.h rpncalc.y rpnlex.c
This is not an error though. Each build node can be marked as precious, using its precious attribute. Precious nodes are not cleared by -c or --clean options, but only by -C and --realclean options[11]. In this particular case, the generated parser files were marked as precious by the mk.make_parser function.
We can continue now to building the calculator executable file:
rpncalc_c, rpncalc_h = mk.make_parser ('rpncalc')
rpnlex_o = mk.compile_source ('rpnlex.c')
mk.depends (rpnlex_o, rpncalc_h)
rpncalc = mk.make_program ('rpncalc', srcs = ['main.c', rpncalc_c],
objs = [rpnlex_o])
mk.env.all.depends (rpncalc)
But[12] if we attempt to build, the linking will fail due to an unresolved reference to the function pow. We should link with the math library libm.a, by passing its name to the function mk.make_program via the named parameter xlibs. Note the difference between libs and xlibs parameters - we can pass either filenames or build node objects via the former and the mk will create a dependency between the libraries and the program, whereas we can pass only library names via the latter and mk will pass them unchanged to the link editor tool for tool specific processing.
So, the mkfile becomes:
rpncalc_c, rpncalc_h = mk.make_parser ('rpncalc')
rpnlex_o = mk.compile_source ('rpnlex.c')
mk.depends (rpnlex_o, rpncalc_h)
rpncalc = mk.make_program ('rpncalc', srcs = ['main.c', rpncalc_c],
objs = [rpnlex_o], xlibs = ['libm.a'])
mk.env.all.depends (rpncalc)
and we can finally build and run the calculator:
$ mk
bison -d -o rpncalc.c rpncalc.y
cc -c -g -o main.o main.c
cc -c -g -o rpncalc.o rpncalc.c
cc -c -g -o rpnlex.o rpnlex.c
cc -g -o rpncalc main.o rpncalc.o rpnlex.o -lm
$ ./rpncalc
6 7 *
42
10 2 5 ^ +
42
[1] The available mk classes are specified in the section called “Build node classes”
[2] The available mk global variables are specified in the section called “Global variables”
[3] Throughout the guide, we will use the term object when talking about objects in the Object-Oriented Programming sense, whereas we will use the term object file when referring to filesystem entities
[4] this and other functions are specified in detail in the section called “Miscelaneous functions”
[5] Nevermind the step6 directory name, it is the top level directory in my source tree, on yours it would be different.
[6] the meaning of the .compile part is explained in the section called “mk.tools.cc”, for now suffice to say that a tool can do more than one thing.
[7] not implemented yet
[8] it is possible one to be a subdirectory of the other
[9] the name, given to the -s option, is available for the mkfiles via the global variable mk.env.output_subdir
[10] e.g. the standard system include directories are usually not searched for dependencies for at least two reasons: a) it's generally hard to detect or specify this information to the mk in a platform and compiler independent manner, and b) the standard system headers usually do not change and thus contribute nothing essential to the build process.
[11] -C,--realclean options remove the cache file too
[12] many “buts” in this section, eh? This was the last one, I promise.
Table of Contents
The non-option arguments, i.e. the arguments, which do not begin with a dash (-) are considered to be target specifications. Target specifications come in three flavors:
Example 3.1. Target specifications
Suppose we have the following files in our project:
$ find build
build
build/src1
build/src1/x.o
build/src1/y.o
build/src2
build/src2/x.o
build/src2/y.o
and the current working directory is build/src2.
The command mk '*.o' builds all the four objects.
The command mk *.o builds src2/x.o and src2/y.o, due to shell expansion.
The command mk '*/x.o' builds src1/x.o and src2/x.o.
Table of Contents
The archiver tool creates and modifies static library archives.
Generic C compiler.
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, the commands you use may
be called something other than `show w' and `show c'; they could even be
mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.
GNU Free Documentation License
Version 1.2, November 2002
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
0. PREAMBLE
The purpose of this License is to make a manual, textbook, or other
functional and useful document "free" in the sense of freedom: to
assure everyone the effective freedom to copy and redistribute it,
with or without modifying it, either commercially or noncommercially.
Secondarily, this License preserves for the author and publisher a way
to get credit for their work, while not being considered responsible
for modifications made by others.
This License is a kind of "copyleft", which means that derivative
works of the document must themselves be free in the same sense. It
complements the GNU General Public License, which is a copyleft
license designed for free software.
We have designed this License in order to use it for manuals for free
software, because free software needs free documentation: a free
program should come with manuals providing the same freedoms that the
software does. But this License is not limited to software manuals;
it can be used for any textual work, regardless of subject matter or
whether it is published as a printed book. We recommend this License
principally for works whose purpose is instruction or reference.
1. APPLICABILITY AND DEFINITIONS
This License applies to any manual or other work, in any medium, that
contains a notice placed by the copyright holder saying it can be
distributed under the terms of this License. Such a notice grants a
world-wide, royalty-free license, unlimited in duration, to use that
work under the conditions stated herein. The "Document", below,
refers to any such manual or work. Any member of the public is a
licensee, and is addressed as "you". You accept the license if you
copy, modify or distribute the work in a way requiring permission
under copyright law.
A "Modified Version" of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with
modifications and/or translated into another language.
A "Secondary Section" is a named appendix or a front-matter section of
the Document that deals exclusively with the relationship of the
publishers or authors of the Document to the Document's overall subject
(or to related matters) and contains nothing that could fall directly
within that overall subject. (Thus, if the Document is in part a
textbook of mathematics, a Secondary Section may not explain any
mathematics.) The relationship could be a matter of historical
connection with the subject or with related matters, or of legal,
commercial, philosophical, ethical or political position regarding
them.
The "Invariant Sections" are certain Secondary Sections whose titles
are designated, as being those of Invariant Sections, in the notice
that says that the Document is released under this License. If a
section does not fit the above definition of Secondary then it is not
allowed to be designated as Invariant. The Document may contain zero
Invariant Sections. If the Document does not identify any Invariant
Sections then there are none.
The "Cover Texts" are certain short passages of text that are listed,
as Front-Cover Texts or Back-Cover Texts, in the notice that says that
the Document is released under this License. A Front-Cover Text may
be at most 5 words, and a Back-Cover Text may be at most 25 words.
A "Transparent" copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the
general public, that is suitable for revising the document
straightforwardly with generic text editors or (for images composed of
pixels) generic paint programs or (for drawings) some widely available
drawing editor, and that is suitable for input to text formatters or
for automatic translation to a variety of formats suitable for input
to text formatters. A copy made in an otherwise Transparent file
format whose markup, or absence of markup, has been arranged to thwart
or discourage subsequent modification by readers is not Transparent.
An image format is not Transparent if used for any substantial amount
of text. A copy that is not "Transparent" is called "Opaque".
Examples of suitable formats for Transparent copies include plain
ASCII without markup, Texinfo input format, LaTeX input format, SGML
or XML using a publicly available DTD, and standard-conforming simple
HTML, PostScript or PDF designed for human modification. Examples of
transparent image formats include PNG, XCF and JPG. Opaque formats
include proprietary formats that can be read and edited only by
proprietary word processors, SGML or XML for which the DTD and/or
processing tools are not generally available, and the
machine-generated HTML, PostScript or PDF produced by some word
processors for output purposes only.
The "Title Page" means, for a printed book, the title page itself,
plus such following pages as are needed to hold, legibly, the material
this License requires to appear in the title page. For works in
formats which do not have any title page as such, "Title Page" means
the text near the most prominent appearance of the work's title,
preceding the beginning of the body of the text.
A section "Entitled XYZ" means a named subunit of the Document whose
title either is precisely XYZ or contains XYZ in parentheses following
text that translates XYZ in another language. (Here XYZ stands for a
specific section name mentioned below, such as "Acknowledgements",
"Dedications", "Endorsements", or "History".) To "Preserve the Title"
of such a section when you modify the Document means that it remains a
section "Entitled XYZ" according to this definition.
The Document may include Warranty Disclaimers next to the notice which
states that this License applies to the Document. These Warranty
Disclaimers are considered to be included by reference in this
License, but only as regards disclaiming warranties: any other
implication that these Warranty Disclaimers may have is void and has
no effect on the meaning of this License.
2. VERBATIM COPYING
You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the
copyright notices, and the license notice saying this License applies
to the Document are reproduced in all copies, and that you add no other
conditions whatsoever to those of this License. You may not use
technical measures to obstruct or control the reading or further
copying of the copies you make or distribute. However, you may accept
compensation in exchange for copies. If you distribute a large enough
number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and
you may publicly display copies.
3. COPYING IN QUANTITY
If you publish printed copies (or copies in media that commonly have
printed covers) of the Document, numbering more than 100, and the
Document's license notice requires Cover Texts, you must enclose the
copies in covers that carry, clearly and legibly, all these Cover
Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
the back cover. Both covers must also clearly and legibly identify
you as the publisher of these copies. The front cover must present
the full title with all words of the title equally prominent and
visible. You may add other material on the covers in addition.
Copying with changes limited to the covers, as long as they preserve
the title of the Document and satisfy these conditions, can be treated
as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit
legibly, you should put the first ones listed (as many as fit
reasonably) on the actual cover, and continue the rest onto adjacent
pages.
If you publish or distribute Opaque copies of the Document numbering
more than 100, you must either include a machine-readable Transparent
copy along with each Opaque copy, or state in or with each Opaque copy
a computer-network location from which the general network-using
public has access to download using public-standard network protocols
a complete Transparent copy of the Document, free of added material.
If you use the latter option, you must take reasonably prudent steps,
when you begin distribution of Opaque copies in quantity, to ensure
that this Transparent copy will remain thus accessible at the stated
location until at least one year after the last time you distribute an
Opaque copy (directly or through your agents or retailers) of that
edition to the public.
It is requested, but not required, that you contact the authors of the
Document well before redistributing any large number of copies, to give
them a chance to provide you with an updated version of the Document.
4. MODIFICATIONS
You may copy and distribute a Modified Version of the Document under
the conditions of sections 2 and 3 above, provided that you release
the Modified Version under precisely this License, with the Modified
Version filling the role of the Document, thus licensing distribution
and modification of the Modified Version to whoever possesses a copy
of it. In addition, you must do these things in the Modified Version:
A. Use in the Title Page (and on the covers, if any) a title distinct
from that of the Document, and from those of previous versions
(which should, if there were any, be listed in the History section
of the Document). You may use the same title as a previous version
if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities
responsible for authorship of the modifications in the Modified
Version, together with at least five of the principal authors of the
Document (all of its principal authors, if it has fewer than five),
unless they release you from this requirement.
C. State on the Title page the name of the publisher of the
Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications
adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice
giving the public permission to use the Modified Version under the
terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections
and required Cover Texts given in the Document's license notice.
H. Include an unaltered copy of this License.
I. Preserve the section Entitled "History", Preserve its Title, and add
to it an item stating at least the title, year, new authors, and
publisher of the Modified Version as given on the Title Page. If
there is no section Entitled "History" in the Document, create one
stating the title, year, authors, and publisher of the Document as
given on its Title Page, then add an item describing the Modified
Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for
public access to a Transparent copy of the Document, and likewise
the network locations given in the Document for previous versions
it was based on. These may be placed in the "History" section.
You may omit a network location for a work that was published at
least four years before the Document itself, or if the original
publisher of the version it refers to gives permission.
K. For any section Entitled "Acknowledgements" or "Dedications",
Preserve the Title of the section, and preserve in the section all
the substance and tone of each of the contributor acknowledgements
and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document,
unaltered in their text and in their titles. Section numbers
or the equivalent are not considered part of the section titles.
M. Delete any section Entitled "Endorsements". Such a section
may not be included in the Modified Version.
N. Do not retitle any existing section to be Entitled "Endorsements"
or to conflict in title with any Invariant Section.
O. Preserve any Warranty Disclaimers.
If the Modified Version includes new front-matter sections or
appendices that qualify as Secondary Sections and contain no material
copied from the Document, you may at your option designate some or all
of these sections as invariant. To do this, add their titles to the
list of Invariant Sections in the Modified Version's license notice.
These titles must be distinct from any other section titles.
You may add a section Entitled "Endorsements", provided it contains
nothing but endorsements of your Modified Version by various
parties--for example, statements of peer review or that the text has
been approved by an organization as the authoritative definition of a
standard.
You may add a passage of up to five words as a Front-Cover Text, and a
passage of up to 25 words as a Back-Cover Text, to the end of the list
of Cover Texts in the Modified Version. Only one passage of
Front-Cover Text and one of Back-Cover Text may be added by (or
through arrangements made by) any one entity. If the Document already
includes a cover text for the same cover, previously added by you or
by arrangement made by the same entity you are acting on behalf of,
you may not add another; but you may replace the old one, on explicit
permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License
give permission to use their names for publicity for or to assert or
imply endorsement of any Modified Version.
5. COMBINING DOCUMENTS
You may combine the Document with other documents released under this
License, under the terms defined in section 4 above for modified
versions, provided that you include in the combination all of the
Invariant Sections of all of the original documents, unmodified, and
list them all as Invariant Sections of your combined work in its
license notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and
multiple identical Invariant Sections may be replaced with a single
copy. If there are multiple Invariant Sections with the same name but
different contents, make the title of each such section unique by
adding at the end of it, in parentheses, the name of the original
author or publisher of that section if known, or else a unique number.
Make the same adjustment to the section titles in the list of
Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections Entitled "History"
in the various original documents, forming one section Entitled
"History"; likewise combine any sections Entitled "Acknowledgements",
and any sections Entitled "Dedications". You must delete all sections
Entitled "Endorsements".
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents
released under this License, and replace the individual copies of this
License in the various documents with a single copy that is included in
the collection, provided that you follow the rules of this License for
verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute
it individually under this License, provided you insert a copy of this
License into the extracted document, and follow this License in all
other respects regarding verbatim copying of that document.
7. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate
and independent documents or works, in or on a volume of a storage or
distribution medium, is called an "aggregate" if the copyright
resulting from the compilation is not used to limit the legal rights
of the compilation's users beyond what the individual works permit.
When the Document is included in an aggregate, this License does not
apply to the other works in the aggregate which are not themselves
derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these
copies of the Document, then if the Document is less than one half of
the entire aggregate, the Document's Cover Texts may be placed on
covers that bracket the Document within the aggregate, or the
electronic equivalent of covers if the Document is in electronic form.
Otherwise they must appear on printed covers that bracket the whole
aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may
distribute translations of the Document under the terms of section 4.
Replacing Invariant Sections with translations requires special
permission from their copyright holders, but you may include
translations of some or all Invariant Sections in addition to the
original versions of these Invariant Sections. You may include a
translation of this License, and all the license notices in the
Document, and any Warranty Disclaimers, provided that you also include
the original English version of this License and the original versions
of those notices and disclaimers. In case of a disagreement between
the translation and the original version of this License or a notice
or disclaimer, the original version will prevail.
If a section in the Document is Entitled "Acknowledgements",
"Dedications", or "History", the requirement (section 4) to Preserve
its Title (section 1) will typically require changing the actual
title.
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except
as expressly provided for under this License. Any other attempt to
copy, modify, sublicense or distribute the Document is void, and will
automatically terminate your rights under this License. However,
parties who have received copies, or rights, from you under this
License will not have their licenses terminated so long as such
parties remain in full compliance.
10. FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions
of the GNU Free Documentation License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns. See
http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number.
If the Document specifies that a particular numbered version of this
License "or any later version" applies to it, you have the option of
following the terms and conditions either of that specified version or
of any later version that has been published (not as a draft) by the
Free Software Foundation. If the Document does not specify a version
number of this License, you may choose any version ever published (not
as a draft) by the Free Software Foundation.
ADDENDUM: How to use this License for your documents
To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and
license notices just after the title page:
Copyright (c) YEAR YOUR NAME.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
replace the "with...Texts." line with this:
with the Invariant Sections being LIST THEIR TITLES, with the
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
If you have Invariant Sections without Cover Texts, or some other
combination of the three, merge those two alternatives to suit the
situation.
If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of
free software license, such as the GNU General Public License,
to permit their use in free software.