Copyright © 1996, 1997 Department of Mathematical and Computing Sciences, Tokyo Institute of Technology. All rights reserved.
Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
1 Introduction | ||
2 Basic Usage | ||
3 Advanced Usage | ||
4 Changes to CLU | ||
5 Library Abstractions | ||
Appendix A How to Install CLU2C | How to install CLU2C | |
Appendix B Copying CLU2C | Conditions for copying CLU2C | |
Index |
CLU2C is an implementation of the programming language CLU. More specifically, it is a CLU compiler with some basic library modules.
The basic strategy is to translate CLU to C. As you might be aware, the name CLU2C stands for ‘CLU to C’.
This manual does not describe CLU itself, although we assume you have some basic knowledge about CLU. See CLU Reference Manual for the language definition.
We use ‘CLU2C’ to denote the whole language system.
We use clu2c
to denote the compiler.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The clu2c
program translates
CLU source files to the equivalent C source files.
The resulting C source files are then compiled and linked
by another program called clulink
.
This chapter describes the basic usage of these two programs.
We often refer to
the clu2c
program as the compiler
and the clulink
program as the linker
in this chapter.
2.1 Getting Started | ||
2.2 Input Files | ||
2.3 Invoking clu2c | ||
2.4 Compiler Behavior | How input files are processed | |
2.5 Invoking clulink |
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
There are two executable programs
named clu2c
and clulink
available to the user.
Use clu2c
for compiling CLU source files
to get intermediate C source files.
Then use clulink
for compiling these intermediate C source files
to get an executable file.
For example, a shell session that compiles a CLU source file named ‘hello.clu’ to get an executable file named ‘a.out’ might look like as follows:
% clu2c hello.clu Creating DU specs from hello.clu time = 0.010 Compiling hello.clu time = 0.010 % clulink hello.c creating hello.o creating op-table.c creating op-table.o creating a.out %
You can see several points from this simple example.
clu2c
program takes names of CLU files as arguments.
clu2c
program creates C files,
whose name is the same as that of CLU file
except that the suffix is replaced with ‘c’.
clulink
program takes names of C files as arguments.
clulink
program creates an executable program named ‘a.out’.
(1)
clulink
program creates auxiliary files,
that is,
object files that correspond to input C files,
a C file named ‘op-table.c’,
and an object file that corresponds to ‘op-table.c’.
You might want to rename ‘a.out’ as a more appropriate name,
say ‘hello’.
You can give ‘-o’ option to clulink
for this purpose:
% clulink -o hello hello.c
This invocation of clulink
creates an executable program named ‘hello’
instead of ‘a.out’.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The compiler accepts several kinds of input files. At the minimum, you need to prepare one or more CLU source files. The other kinds of input files are optional. By convention, each kind of input files should have a specific suffix.
This is a CLU source file, which consists of one or more modules. The primary task of the compiler is to translate this file to an equivalent C source file named ‘name.c’.
This is an equate file, which consists of one or more equates. Equates in this file work as if they were placed at the beginning of the pseudo top-level scope that contains the entire source program. This top-level scope is special in the sense that identifiers introduced in it may be redefined in its nested scopes.
This is an interface specification file, which consists of one or more interface specifications. An interface specification is a module that suppresses all constructs that would not affect the interface of the abstraction the module would implement. In other words, it is something like a module but lacks the following constructs:
rep
in clusters
Strictly speaking, such constructs are accepted but simply discarded. This file become needed when the compiler has no access to CLU source files that contain modules of which the compiler wants to know interfaces.
This is an interface specification library file.
This is not a text file.
Usually this file is created when clu2c
is invoked
with the -d
option.
This file may be used in order to collect interface specifications
from CLU source files and interface specification files
and arrange them into a single file.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
clu2c
An invocation of clu2c
has either of the following two forms:
clu2c [option…] input_spec… clu2c [command_invocation…]
where ‘[a]’ means that a is optional
and ‘a…’ means a sequence of one or more a’s.
This section describes only the first form of invocations;
description about the second form is deferred to Advanced Usage.
For the time being,
all you should know about the second form is
that you can terminate clu2c
by typing ‘quit’
when it is unintentionally invoked with no arguments.
2.3.1 Options for clu2c | ||
2.3.2 Specifying Input Files |
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
clu2c
The compiler recognizes the following options in the command line. Most options have both short forms (single hyphen followed by one character) and a long forms (double hyphens followed by option name). In this chapter options are generally referred in a short form only.
Normally CLU source files specified in a command line undergo two stages of processes: extraction of interfaces and compilation. This option inhibits the first stage from taking place. This option may be used when the interfaces of the modules defined in the specified CLU source files are given to the compiler from other input files (i.e., interface specification files or interface specification library files).
The compiler gathers intefaces of the abstractions
from various input files
during processing them.
This option causes these intefaces to be dumped,
after all the compilation is completed,
to the file specified by file
as an interface specification library file.
If file has no suffix,
it specifies the file ‘file.lib’.
This option corresponds to the dump
command of the compiler
Produce C source files even if any error is detected during compilation.
This option is intended to be used by the
developer and the use by the user is generally discouraged.
This option corresponds to the allow
command of the compiler
Executes commands of the compiler in the file specified by file.
If file has no suffix,
the compiler first attempts to read the file ‘file.xfile’.
This option corresponds to the xfile
command of the compiler
Produce debugging information and inlay it into the generated C source files.
This information will be used by the debugger
(We are developing a source-level CLU debugger called cludb
,
which is not yet publicly available).
This option corresponds to the debug
command of the compiler
Display a brief summary of the usage of the compiler.
This option corresponds to the help
command of the compiler
Run the compiler in the ‘make’ mode. In this mode, the compiler automatically detects CLU source files that need to be compiled in the working directory and compiles them. The compiler maintains three auxiliary files: ‘Depend’, ‘Location’, and ‘SPC.lib’. These files are created in the same directory where C source files are created. See … for more detail.
Display the commands of the compiler that would be executed unless this option is specified.
Specifies mode as an optimization mode.
There are three optimization modes:
false
,
time
,
and space
.
The optimization mode is set to false
unless this option is specified.
If mode is omitted,
then time
is assumed.
This option corresponds to the optimize
command of the compiler
Check the code for syntactic errors, and do not process any further.
Normally CLU source files specified in a command line undergo two stages of processes: extraction of interfaces and compilation. This option inhibits the second stage from taking place.
Check the code for syntactic and semantic errors, and do not process any further.
Output cross-reference table for external names.
Tells the compiler
that the version number of char
will be used
with the generated C files.
This command is primarily for developers only.
Tells the compiler
that the version number of string
will be used
with the generated C files.
This command is primarily for developers only.
Some options are exclusive: you must not specify two or more among the ‘-p’ option, the ‘-s’ option, and the ‘-t’ option.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You can specify input files by simply listing their names. For example, suppose that you have three CLU source files named ‘foo.clu’, ‘bar.clu’, and ‘baz.clu’ in the current working directory. You can directly specify these files by listing their names as:
foo.clu bar.clu baz.clu
Generally speaking, the compiler receives a list of input specifications. An input specification is either a file specification or an indirect specification. A file specification is a file name except that ‘*’ is treated as a wild card character as in most shells. An indirect specification is ‘@’ followed by a file name. The named file must contain input specifications, one for each line. In either case, an input specification expands to a list of file names.
• Default Suffix | ||
• Globbing Input Files | ||
• Indirect Specifications |
There is a default suffix specific to the context where input specifications are interpreted. Any input file name with a default suffix can be specified without a suffix. When an input specification does not have a suffix apparently, a file name derived by appending a default suffix is tried first. If such a file exists, the specification is interpreted as specifying this file; otherwise it is treated as is with respect to the suffix.
The default suffix is ‘clu’
for input specifications in a shell command line
that invokes clu2c
,
except for file names in indirect specifications.
For example,
when clu2c
is invoked as
clu2c foo
then the compiler first checks if ‘foo.clu’ exists. If it does, the compiler reads ‘foo.clu’; otherwise it reads ‘foo’.
The ‘*’ character is treated as a meta-character that matches zero or more sequence of any characters, as in most shells. Although your shell probably expands ‘*’ in a shell command line by itself, the compiler expands ‘*’ wherever an input specification is expected.
For example, you can specify all CLU source files in the current working directory as:
*.clu
You can specify input files indirectly through a file. If an input specification begins with ‘@’, the rest of the specification is treated as specifying a file that contains a list of input specifications, one specification per line. The default suffix for this file, sometimes called a ‘response file’, is ‘xload’.
Note that each line in this file is not just a file name but an input specification: the default suffix and file name globbing still work.
For example, suppose you have a file named ‘sources.xload’ that consists of the following three lines:
foo.clu bar.clu baz.clu
Then the specification
@sources.xload
is completely equivalent to the following input specifications
foo.clu bar.clu baz.clu
The default suffix for a file that follows ‘@’ is ‘xload’. Thus you can also specify as:
@sources
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Normally CLU source files undergo two stages of processes.
In the first stage,
interface specifications are extracted;
in the second stage,
code generation takes place.
Some options change this behavior.
If you specify the -t
option,
the second stage stops
when type-checking and some other validity-checking have been completed.
If you specify the -s
option,
the second stage is not performed.
If you specify the -p
option,
only syntactic validity is checked.
If you specify one of these options,
no code is generated.
Equate files are …
Interface specification files are …
Interface specification library files are …
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
clulink
The clulink
program recognizes the following options
to control how it operates:
Print the version of clulink
.
Generate debugging information, as in the C compiler.
Print the brief description of the usage.
Print additional messages.
Specify the name of the output file.
Append directory to the library search path.
Link an archive associated with name.
Use compiler as a C compiler.
Pass flag to the C compiler.
Use plink as a pre-linker.
Force compilation.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
(This chapter may be skipped initially.)
As a matter of fact, clu2c
is a command interpreter.
The user might be unaware of this fact
so long as (s)he uses clu2c
through the command line interface,
and it is sufficient in most situations.
Sometimes,
however,
it may be necessary to control the compiler more closely
by issuing a sequence of commands.
There are two ways to give commands directly to the compiler.
First,
the compiler reads commands from the standard input
if it is invoked without arguments.
Secondly,
if the compiler is invoked with the -f
option,
it reads commands from the specified file.
In order to know how to use commands for clu2c
,
you need to understand the compiler’s internal architecture to some extent,
especially the compilation environment and the interface specification library.
3.1 Command Syntax | ||
3.2 Compiler Invocation Revisited | How command line is interpreted | |
3.3 Compilation Environment | You can define global constants | |
3.4 Interface Specification Library | Type-check | |
3.5 Compilation Commands | ||
3.6 Changing Code Generator’s Behavior | ||
3.7 Miscellaneous Commands | Other commands | |
3.8 Invoking plink |
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A command invocation has a form:
command_name [ argument… ]
where [ x ] means an optional x
and x… means one or more sequence of x.
The number and the kind of the arguments depend on which command is invoked.
command_name
is case-insensitive
and can be specified with an unambiguous prefix.
Some commands take a boolean value as an argument. Specify ‘true’ or ‘false’. This is again case-insensitive and can be specified with an unambiguous prefix.
Some commands take a list of input specifications as arguments. In the description of such commands, input_spec is used. See section Specifying Input Files, for syntax and semantics of input specifications.
You can specify two or more commands,
separated by semicolons,
in one line.
For example,
to specify specs
and compile
commands in one line,
do like this:
specs foo.clu; compile foo.clu
You can use a sharp sign (‘#’) instead of a semicolon for backward compatibility.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When the compiler is invoked with arguments, it first converts them into a sequence of command invocations and then executes them in order.
For example,
suppose clu2c
is invoked as follows:
clu2c -s -d foo foo.lib foo.clu bar.clu baz.clu
Then,
clu2c
converts the command line arguments
into the following command sequence
and executes them in order.
merge foo.lib specs foo.clu bar.clu baz.clu dump foo.lib
3.2.1 Options Conversion | How options are converted to commands | |
3.2.2 Input Files Conversion | How input files are converted to commands |
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The -n
option lets the compiler show what commands would be executed
but do not actually execute them.
This option can be used to see
how command line arguments are converted to a sequence of command invocations.
The -p
option,
the -s
option,
and the -t
option change the compiler’s behavior
with respect to what kind of command(s) are applied to input files (see below).
The other options are converted to commands directly:
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Input files are grouped on the per-suffix basis. Then one or two commands are applied to each group.
specs
and compile
commands are applied
to CLU source files.
If the -t
option is specified,
the check
command is applied instead of compile
.
If the -s
option is specified,
the specs
command only is applied.
If the -p
option is specified,
the parse
command only is applied.
ce
command is applied to the first group
and xce
to the subsequent groups.
-p
option is specified,
the parse
command is applied instead.
merge
command is
applied.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The clu2c
program maintains a set of equates
called compilation environment or CE for short.
The compiler process starts with an empty CE.
Then the user can append equates to the CE
using ce
and xce
commands.
When the compiler detects a free identifier, i.e., identifier that is used but not declared nor defined in the module to be compiled, it first looks up the equate that defines the identifier in the CE. If such an equate is found, right hand side of the equate is used as a value of the identifier.
The following commands are provided as operations on CE. The default suffix for input files is ‘equ’.
• ce | ||
• xce |
Discard all the equates in the current CE and use the set of equates described in the input files as a new CE.
Add equates described in the input files to the current CE.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In order to type-check a module, interface specifications of all the abstractions that are referred by the module must be known. The compiler has an internal table for storing interface specifications of abstractions. We call this table interface specification library.
Initially, interface specifications of built-in types and type generators, together with standard I/O abstractions, are registered in the interface specification library.
The following commands are provided as operations on the interface specification library.
• specs | ||
• dump | ||
• merge | ||
• unmerge | ||
• forget | ||
• newlib |
Extracts interface specifications from input files, and enters these specifications in the specification library. The default suffix is ‘spc’ or ‘clu’.
Dumps the content of the specification library to the file named filename. The default suffix is ‘lib’.
Reads interface specifications from the input files,
which is previously dumped using the dump
command,
and merges them into the specification library.
The default suffix for input files is ‘lib’.
Reads interface specifications from the input files,
which is previously dumped using the dump
command,
and deletes the interface specifications for these modules.
The default suffix for input files is ‘lib’.
Deletes the interface specification of module from the specification library.
Resets the specification library to its initial state.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
• compile | ||
• check | ||
• parse |
Produces binary output. A binary file is produced only if there are no errors. Hence, if a binary file is produced, any messages are warnings, not errors.
Does type- and legality- checking.
Just parses the files, checking for syntactic errors.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
• allow | ||
• binsuf | ||
• char-version | ||
• debug | ||
• optimize | ||
• safe | ||
• string-version |
If boolean implies ‘true’,
the subsequent invocations of the
compile
command always produce (maybe incomplete) C source files
even if any error is detected. If ‘false’ is implied, this
behavior is canceled. This command is intended to be used by the
developer and the use by the user is discouraged.
Sets the suffix for binary files. The default is ‘c’. If no argument is given, resets to the default. If ‘*’ is given, no suffix will be used. This is useful when creating library binaries.
Tells the compiler
that the version number of char
will be used
with the generated C files.
This command is primarily for developers only.
time
|space
|false
]If no argument is specified,
the default is time
.
The optimization mode affects all subsequent compilations.
space
causes only optimizations that do not increase the code size.
time
additionally performs optimizations
that can increase the code size.
Optimization eliminates many traceable routine calls,
and so should only be used on well-debugged programs.
See also the locals
command.
In safe mode,
each module to be compiled is checked
to make sure its name does not clash with an existing module name
in the CLU system.
This is done by looking in the file ~CLU/system.names.
The initial mode is false
.
Tells the compiler
that the version number of string
will be used
with the generated C files.
This command is primarily for developers only.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This subsection describes miscellaneous commands not described in the above subsections.
• expunge | ||
• externals | ||
• force | ||
• help | ||
• locals | ||
• quit | ||
• xfile |
In expunge
mode,
only the interfaces of clusters are remembered;
the interfaces of external routines are not.
The compiler normally outputs a cross-reference of references to external modules. This command can be used to stop that output.
This command is recognized for backward compatibility but no longer has any effect.
Prints a brief summary of the commands.
This command is recognized for backward compatibility but no longer has any effect.
Terminates the compiler process.
Reads a list of commands from input files and executes them in order. The default suffix for input files is ‘xfile’.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
plink
The plink
program is a pre-linker
for C files which are generated by clu2c
.
It has two modes: normal mode and extraction mode.
In normal mode,
plink
reads C files generated by clu2c
and produces an auxiliary C file
which contains various variable/function definitions
that cannot be fixed until all the C files are prepared.
In extraction mode,
plink
extracts C comments related to plink
from the specified C files,
which may be the input for later plink
execution.
plink
is invoked through the clulink
program.
Users rarely invoke plink
directly.
The plink
program recognizes the following options.
Produces an output C source file by the name file. The name of the default object file is ‘op-table.c’ in normal mode; put to standard output by default in extraction mode.
Executes plink
in extraction mode.
In this mode,
plink
extracts,
from input files,
C comments that make sense for plink
.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
4.1 Lexical Changes | ||
4.2 Start-up Procedure | ||
4.3 Object-Oriented Invocation | ||
4.4 Failure Result | ||
4.5 Notes on File Names |
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A particular subset of JIS X0208 is permitted in tokens and separators.
Some characters defined in JIS X0208
are conceptually equivalent to those in ASCII
(see the table below).
Such characters are not distinguished in source code
except for char
and string
literals,
excluding surrounding quotes.
==================================== ASCII JIS X0208 equivalent (kuten) ------------------------------------ SP 1-1 ! 1-10 " 1-41 # 1-84 $ 1-80 % 1-83 & 1-85 ' 1-39 ( 1-42 ) 1-43 * 1-86 + 1-60 , 1-4 - 1-61 . 1-5 / 1-31 0...9 3-16...3-25 : 1-7 ; 1-8 < 1-67 = 1-65 > 1-68 ? 1-9 @ 1-87 A...Z 3-33...3-58 [ 1-46 \ 1-79 ] 1-47 ^ 1-16 _ 1-18 ` 1-38 a...z 3-65...3-90 { 1-48 | 1-35 } 1-49 ~ 1-17 ------------------------------------
An identifier can contain JIS X0208 ‘hiragana’, ‘katakana’, ‘kanji’, Greek letters, Cyrillic letters, and special characters in the following table.
================================================= Kuten Description ------------------------------------------------- 1-11 `dakuten' 1-12 `han-dakuten' 1-19 `katakana' repetition symbol 1-20 `katakana' repetition symbol (`dakuten') 1-21 `hiragana' repetition symbol 1-22 `hiragana' repetition symbol (`dakuten') 1-25 repetition symbol 1-28 `cho-on' symbol -------------------------------------------------
Comments can contain any JIS X0208 characters.
A new punctuation symbol ‘!’ can be used.
A new escape sequence of the form \xhhhh
can be used.
effects Returns the minimum number of bytes required to represent c.
effects This operation is equivalent to the following:
width = proc (s: string) returns (int) w: int := 0 for c: char in string$chars (s) do w := w + char$width (c) end return (w) end width
modifies
s
effects
Changes the coding system for s to code.
effects Returns the coding system for s.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The definition of CLU does not specify how program execution begins.
In CLU2C,
program execution begins by invoking a procedure named start_up
.
This procedure is called the start-up procedure.
There is no way to use another name for it.
It is up to the programmer to implement the start-up procedure.
It must have the following heading:
start_up = proc ()
That is, it takes no arguments and terminates in either of:
failure
condition with a string result.
When start_up
signals the failure
exception,
the run-time system attempts to print the result to the standard error
before it terminates the program execution.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
An object-oriented invocation has the following two forms:
primary!name [()] primary!name (expression, …)
These forms are just syntactic sugar for an operation invocation and are completely equivalent to (respectively):
T$name (primary) T$name (primary, expression, …)
where T is the type of primary.
For example,
if a
is an array of integers,
then
a!addh (1)
is completely equivalent to the invocation
array[int]$addh (a, 1)
Note that they are syntactic sugar: they by no means enable dynamic dispatching of operations. Remember that CLU is an almost statically-typed language.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
According to the definition of CLU, an exception not handled in a routine becomes
failure ("unhandled exception: exception_name")
where exception_name is the name of the unhandled exception. In CLU2C, this transformation is slightly modified: the unhandled exception named exception_name becomes
failure ("unhandled exception: exception_name in routine_name")
where routine_name is the name of the routine that did not handle the exception. This will help you find where the problem is. Similarly, if a procedure that should return results in the normal condition reaches the textual end of its body, it signals
failure ("no return values in procedure_name")
rather than
failure ("no return values")
where procedure_name is the name of the procedure.
This modification is canceled when you compile source code in optimization mode.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Implementation of file_name
is dependent on the target file system.
CLU2C provides two implementations for file_name
:
one for UNIX file system,
and the other for MS-DOS file system.
It is determined at installation-time which implementation is available to the user.
This chapter describes some details about file names not described in CLU Reference Manual and specific to CLU2C.
4.5.1 File Name Components | ||
4.5.2 Parsing Strings as File Names |
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In terms of file_name
,
file names are viewed as consisting of four string components:
directory
,
name
,
suffix
,
and other
.
In CLU2C,
any component may be empty.
name
component cannot contain any path delimiters.
suffix
component must be empty if the name
component is empty.
suffix
component cannot contain any path delimiters nor any periods.
other
component must be empty.
On UNIX systems,
On MS-DOS systems,
file_name$create
and file_name$parse
also interprets
a slash character as a path delimiter
(this seems to be a common convention).
directory
component may start with a drive specification,
i.e.,
drive name (from ‘a’ to ‘z’) followed by a colon.
We refer to the rest of the directory
component after the drive specification
as a proper directory.
For example,
suppose the directory
component of a file name is ‘c:\bin\clu2c’.
In this case,
the drive specification is ‘c:’
and the proper directory is ‘\bin\clu2c’.
file_name$create
and file_name$parse
operations convert
ASCII uppercase letters into corresponding ASCII lowercase letters,
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The file_name$parse
operation parses the given string argument
and creates a file name.
The primary task of this operation is to split the argument into four components
(actually three, since the other component is always empty).
directory
component and a non-directory.
If the string contains any path delimiters,
the last path delimiter splits it into them;
otherwise directory is empty and the whole string is non-directory.
Tilde notations for specifying home directory work. Especially, ‘~CLU’ denotes the CLU2C system root directory (typically ‘/usr/local/lib/clu2c’).
Here are some examples, where resulting file name objects are written in the form of {directory, name, suffix, other}:
file_name$parse("/") ⇒ {"/", "", "", ""} file_name$parse(".cshrc") ⇒ {"", ".cshrc", "", ""} file_name$parse("/usr/local/src/clu2c.tar.gz") ⇒ {"/usr/local/src", "clu2c.tar", "gz", ""}
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
5.1 Directory Entries | ||
5.2 File Operations | ||
5.3 File Name Handling | ||
5.4 Integer Handling | ||
5.5 Mathematical Functions | ||
5.6 Program Environment | ||
5.7 Miscellaneous Abstractions |
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You can merge ‘~CLU/lib/dirent.lib’ to get the interface specifications of the abstractions described in this section.
• directory_entry_names |
effects Yields names of the entry in dir in an arbitrary order.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You can merge ‘~CLU/lib/file.lib’ to get the interface specifications of the abstractions described in this section.
5.2.1 Distinguishing Kinds of Files |
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
• file_is_block_device | ||
• file_is_character_device | ||
• file_is_directory | ||
• file_is_fifo | ||
• file_is_regular | ||
• file_is_symbolic_link |
effects
Returns true
if a file named fn exists
and it is a block device;
otherwise returns false
.
effects
Returns true
if a file named fn exists
and it is a character device;
otherwise returns false
.
effects
Returns true
if a file named fn exists
and it is a directory;
otherwise returns false
.
effects
Returns true
if a file named fn exists
and it is a fifo (i.e., named pipe);
otherwise returns false
.
effects
Returns true
if a file named fn exists
and it is a regular file;
otherwise returns false
.
effects
Returns true
if a file named fn exists
and it is a symbolic link;
otherwise returns false
.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You can merge ‘~CLU/lib/filename.lib’ to get interface specifications of the abstractions described in this section.
5.3.1 Accessing File Name Components | ||
5.3.2 Transforming File Names | ||
5.3.3 Specific File Names |
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
• file_name_nondirectory | ||
• file_name_drive | ||
• file_name_proper_directory |
effects This procedure is equivalent to the following:
file_name_nondirectory = proc(fn: fname) returns(string) fname = file_name entry: fname := fname$create("", fn.name, fn.suffix, fn.other) return(fname$unparse(entry)) end file_name_nondirectory
This procedure transforms fn
in a string representation like file_name$unparse
as if the directory component of fn was empty.
effects On UNIX this procedure returns an empty string. On MS-DOS this procedure returns a drive specification in the directory component of fn if it exists; otherwise returns an empty string.
effects
On UNIX this procedure is equivalent to file_name$get_dir
.
On MS-DOS
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
• file_name_fill_directory | ||
• file_name_fill_suffix | ||
• file_name_apply_directory | ||
• file_name_absolutize | ||
• file_name_is_absolute | ||
• file_name_simplify | ||
• file_name_expand_home_directory | ||
• file_name_as_directory | ||
• directory_file_name |
effects This procedure fills in or fixes up the directory component of fn if it is empty or relative; otherwise merely returns fn. The result may or may not be absolute. If the result is not absolute, it will be treated as relative to the current working directory associated with the current process.
effects
If the suffix
component of fn is empty
and suffix is valid as a suffix
component,
an invocation of this procedure is equivalent to the following invocation:
file_name$create(fn.dir, fn.name, suffix, fn.other)
Otherwise simply returns fn.
effects
effects
effects
Returns true
if fn represents an absolute file name;
otherwise returns false.
effects
effects
Directory names are file names such that all the components other than directory are empty.
effects
effects
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
• current_directory | ||
• home_directory |
effects Returns the current working directory associated with the currently executing process.
effects
Returns user’s home directory if it can be determined;
otherwise signals not_found
.
An empty user implies the user associated with the currently executing process.
The "CLU" user is treated as to have the CLU system root directory as its home directory.
The result is a directory name,
i.e., all the components other than directory are empty.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This section describes some auxiliary operations on int
.
You can merge ‘~CLU/lib/int.lib’
to get interface specifications of the abstractions
described in this section.
• int_hex_parse | ||
• int_hex_unparse | ||
• int_oct_parse | ||
• int_oct_unparse |
effects
Equivalent to int$parse
except that each digit in s shall be hexadecimal.
The letters from ‘a’ (or ‘A’) through ‘f’ (or ‘F’)
are used as hexadecimal digits
with values from 10 through 15,
respectively.
effects
Equivalent to int$unparse
except that each digit in the result is hexadecimal.
The letters from ‘a’ through ‘f’
are used for hexadecimal digits
with values from 10 to 15,
respectively.
effects
Equivalent to int$parse
except that each digit in s shall be octal.
effects
Equivalent to int$unparse
except that each digit in the result is octal.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The overflow
exception occurs
if the magnitude of the result is greater than Real_Max,
unless otherwise specified.
The underflow
exception occurs
if the magnitude of the result is less than Real_Min,
unless otherwise specified.
Interface specifications of these functions are contained in ‘~CLU/lib/math.spc’.
5.5.1 Trigonometric Functions | ||
5.5.2 Hyperbolic Functions | ||
5.5.3 Exponential and Logarithmic Functions | ||
5.5.4 Power Functions |
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In the following descriptions, ‘PI’ denotes the ratio of the circumference of a circle to its diameter.
• acos | ||
• asin | ||
• atan | ||
• atan2 | ||
• cos | ||
• sin | ||
• tan |
effects
Signals bounds
if x is less than -1 or greater than 1;
otherwise returns the arc cosine of x in the range [0, PI] radians.
effects
Signals bounds
if x is less than -1 or greater than 1;
otherwise returns the arc sine of x in the range [-PI/2, +PI/2] radians.
effects Returns the arc tangent of x in the range [-PI/2, +PI/2] radians.
effects
Signals undefined
if both x and y are zero;
otherwise returns the arc tangent of y/x in the range [-PI, +PI] radians.
effects Returns the cosine of x (measured in radians).
effects Returns the sine of x (measured in radians).
effects Returns the tangent of x (measured in radians).
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
• cosh | ||
• sinh | ||
• tanh |
effects Returns the hyperbolic cosine of x.
effects Returns the hyperbolic sine of x.
effects Returns the hyperbolic tangent of x.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
• exp | ||
• log | ||
• log10 |
effects Returns the exponential function of x.
effects
Signals complex_result
if x is negative;
signals undefined
if x is zero;
otherwise returns the natural logarithm of x.
effects
Signals complex_result
if x is negative;
signals undefined
if x is zero;
otherwise returns the base-ten logarithm of x.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Note that a general power function is implemented as the real$power
operation.
• sqrt |
effects
Signals complex_result
if x is negative;
otherwise returns the square root of x.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You can merge ‘~CLU/lib/progenv.lib’ to get interface specifications of the abstractions described in this section.
5.6.1 Argument Vector | ||
5.6.2 Option Handling | ||
5.6.3 Environment Variables | ||
5.6.4 System Command Execution | ||
5.6.5 Program Termination |
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
• program_name | ||
• program_arguments | ||
• input_streams |
effects Returns the program name associated with the current process.
effects Returns the program arguments associated with the current process.
effects
Yields the primary input stream if inputs is empty
(the primary input stream is the stream
returned by the stream$primary_input
operation).
Otherwise yields an input stream specified by each element of inputs,
in order.
If an element of inputs is ‘-’,
it specifies the primary input stream.
Any other elements specify input streams
that result from opening files named by those elements.
If a named file cannot be opened,
prints an error message to the primary output stream for error messages
(returned by the stream$error_output
operation)
and yields nothing as far as that element of inputs is concerned.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The getopt
type provides the means
to analyze the argument vector (sometimes called an argv)
supplied to a program when it was invoked.
From the point of view of getopt
,
an argument vector consists of zero or more option arguments
followed by zero or more non-option arguments.
Option arguments specify a set of options.
An option can take an argument for itself.
The argument that starts with a minus sign (-
)
followed by one or more characters
is an option argument unless otherwise specified.
It specifies one or more options.
If an option specified by an option argument takes an argument
and an argument to the option is not specified in the option argument,
the next argument in the argument vector
is taken as an argument to the option.
At the minimum,
an option argument consists of a minus sign
followed by a single character (e.g., -a
),
which specifies a single option.
If an option takes an argument,
the argument to the option can be specified in the same option argument.
For example,
suppose that the -o
option takes an argument.
The argument to this option,
say foo
,
can be specified as -ofoo
,
as well as -o foo
,
as mentioned above.
Options specified by a single character can be grouped into a single option argument.
For example,
the three options -a
, -b
, and -c
can be specified as -abc
.
Note that an argument-taking option eats up an option argument.
For example,
if the -o
option takes an argument as before,
the option argument -aobc
is equivalent to the tree option arguments -a -o bc
.
An getopt
object can be made tailored
to recognize long-form options
(in contrast to short-form options described so far).
The form of an long-form option is
--
name[=
argument]
where name can be specified with an unambiguous prefix.
A special option argument
that consists of two minus signs (i.e., --
),
unless taken as an argument for the preceding option,
does not modify the program behavior
but modifies the way the argument vector is analyzed:
it specifies the end of option arguments.
That is,
all the arguments that follows this argument
are taken as non-option arguments,
even if they start with a minus sign.
An getopt
object is mutable.
The state of an getopt
object changes
during the execution of the options
operation.
No other operations change the state.
Each time the options
operation yields,
it sets the current option to the yielded one.
• getopt$create | ||
• getopt$create_long | ||
• getopt$options | ||
• getopt$get_optname | ||
• getopt$get_optarg | ||
• getopt$optarg_is_empty | ||
• getopt$optarg_is_full | ||
• getopt$get_optind | ||
• getopt$get_opterr | ||
• getopt$set_opterr | ||
• getopt$set_output | ||
• getopt$get_non_options | ||
• getopt$non_options |
effects
Returns a new getopt
object
that analyzes short-form options in argv.
The legitimate characters for the options are listed in optstring.
If a character is followed by a colon (:
),
the option specified by the character takes an argument.
The other options does not take an argument.
Signals bad_format
if optstring is empty
or it starts with a colon.
effects
Returns a new getopt
object
that analyzes short-form options as well as long-form options in argv.
The shortopts
argument
is the same as optstring for create
except that it can be empty,
in this case only long-form options are analyzed.
The longopts argument specifies a set of legitimate long-form options.
Each element specifies a single long-form option.
The name
component is the name of the option.
The arg
component specifies whether the option takes an argument:
no_argument
means that the option does not take an argument;
required_argument
means that the option takes an argument;
optional_argument
means that the option takes an argument
but the argument can be omitted.
The val
component specifies the character
yielded by the options
operation when the option is encountered.
Signals bad_format
if shortops starts with a colon
or longopts is not in the form mentioned above.
requires
The options
operation has not been invoked on go.
modifies
go.
effects
Analyzes the argument vector and yields a character
that corresponds to the option encountered.
If the option is in short form,
yields the character that specifies the option.
If the option is in long form,
yields the val
component that corresponds to the option.
If the specified option is not legitimate,
is ambiguous,
or lacks a required argument,
yields a question mark (?
).
In the last case an error message is printed to the standard error.
effects Returns the name of the current option such as "-a" or "–verbose".
effects
If the current option has an argument,
returns the argument.
Otherwise signals no_argument
.
effects
Returns true
if and only if the current option does not have an argument.
effects
Returns true
if and only if the current option has an argument.
effects Returns the index of the next argument to be processed in the argument vector.
effects Returns whether an error message is printed when an option is unknown or without a required argument.
modifies
go.
effects
If opterr is true
,
changes go so that an error message is printed
when an option is unknown or without a required argument
(this is the default behavior).
Otherwise changes go so that no error messages are printed.
modifies
go.
effects
Changes go so that error messages are printed to output.
requires
The options
operation has been invoked on go
and it terminated normally.
effects
Returns the sequence of the non-option arguments.
requires
The options
operation has been invoked on go
and it terminated normally.
effects
Yields each non-option argument in the same order
as in the argument vector that is used for creating go.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
effects
Returns the value of the environment variable associated with name
if such a variable exists;
otherwise signals not_found
.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
effects Invokes an implementation-defined command processor to interpret command and returns an implementation-defined value.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
effects Attempts to flush all open streams with unwritten buffered data, then closes all open streams, and then terminates the current process in the condition specified by status.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
5.7.1 Unsigned Integers |
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Objects of type uint
are immutable
and represent nonnegative integers less than UINT_MODULO,
where UINT_MODULO = 2 ** UINT_BIT
and UINT_BIT is the implementation-defined constant
such that UINT_MODULO > Int_Max.
• uint$create | ||
• uint$to_int | ||
• uint$add | ||
• uint$sub | ||
• uint$mul | ||
• uint$div | ||
• uint$mod | ||
• uint$max | ||
• uint$min | ||
• uint$lt | ||
• uint$le | ||
• uint$ge | ||
• uint$gt | ||
• uint$and | ||
• uint$or | ||
• uint$xor | ||
• uint$not | ||
• uint$shift | ||
• uint$parse | ||
• uint$hex_parse | ||
• uint$oct_parse | ||
• uint$unparse | ||
• uint$hex_unparse | ||
• uint$oct_unparse | ||
• uint$equal | ||
• uint$similar | ||
• uint$copy |
effects
Signals negative_argument
if i < 0;
otherwise returns the unsigned integer that has the same value as i.
effects
Signals overflow
if u can not be represented as an int
object;
otherwise returns the integer that has the same value as u.
effects u3 is congruent to (u1 + u2) (modulo UINT_MODULO).
effects u3 is congruent to (u1 - u2) (modulo UINT_MODULO).
effects u3 is congruent to (u1 * u2) (modulo UINT_MODULO).
effects
Signals zero_divide
if u2 is zero;
otherwise u1 is equal to (u2 * u3 + r)
for some nonnegative integer r less than u2.
effects
Signals zero_divide
if u2 is zero;
otherwise u3 is less than u2
and u1 is equal to (u2 * q + u3)
for some nonnegative integer q.
effects Returns the larger of u1 and u2.
effects Returns the smaller of u1 and u2.
effects
Returns true
if and only if u1 is less than u2.
effects
Returns true
if and only if u1 is less than or equal to u2.
effects
Returns true
if and only if u1 is greater than or equal to u2.
effects
Returns true
if and only if u1 is greater than u2.
effects Returns the bitwise AND of u1 and u2.
effects Returns the bitwise inclusive OR of u1 and u2.
effects Returns the bitwise exclusive OR of u1 and u2.
effects Returns the one’s complement of u.
effects Returns an unsigned integer that is the result of shifting u left by count bit positions if count is positive; otherwise returns an unsigned integer that is the result of shifting u right by -count bit positions.
effects
Signals bad_format
if s contains any character other than decimal digits;
otherwise u is congruent
to the integer represented by s
(modulo UINT_MODULO).
effects
Signals bad_format
if s contains any character other than hexadecimal digits;
otherwise u is congruent to x
(modulo UINT_MODULO),
where x is the integer represented by s in hexadecimal notation.
effects
Signals bad_format
if s contains any character other than octal digits;
otherwise u is congruent to x
(modulo UINT_MODULO),
where x is the integer represented by s in octal notation.
effects Returns the string such that parse(unparse(u)) = u. Leading zeros are suppressed.
effects Returns the string such that hex_parse(hex_unparse(u)) = u. Leading zeros are suppressed. The letters from ‘a’ through ‘f’ are used for hexadecimal digits with values from 10 to 15, respectively.
effects Returns the string such that oct_parse(oct_unparse(u)) = u. Leading zeros are suppressed.
effects
Returns true
if and only if u1 and u2 is the same unsigned integer.
effects
Equivalent to the equal
operation.
effects Simply returns u.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A.1 Basic Installation | The simplest installation instructions | |
A.2 Configurations | How to run the configure script
| |
A.3 MS-DOS Installation | How to install on MS-DOS systems | |
A.4 Compiling in a Separate Directory | How to compile in a separate directory | |
A.5 Common Targets | What to make | |
A.6 Makefile Structure | Makefile consists of three parts | |
A.7 Getting CLU2C | How to obtain distribution packages |
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This section shows basic instructions for installing CLU2C on UNIX systems. See section MS-DOS Installation, for the instructions for installing CLU2C on MS-DOS systems. Now we assume that you have unpacked the source distribution package and are at the top source directory.
configure
script.
This script creates a number of files
including ‘config.h’ and ‘config.mk’
in the current working directory,
and also creates ‘Makefile’ in every directory.
See section Configurations,
for more detail about the configure
script.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
CLU2C source distribution package
comes with a shell script named configure
,
which automatically guesses various system-dependent parameters
used to compile the package.
The first thing to do for installation is running this script.
After guessing system-dependent parameters,
configure
creates the files ‘config.h’,
‘config.mk’,
‘config.status’,
‘config.cache’,
‘config.log’,
and ‘fakeclu.sh’ in the current directory,
as well as the files ‘Makefile’ and ‘Makefile.top’
in every directory.
A.2.1 Options for configure | ||
A.2.2 Presetting ‘Makefile’ Variables | Presetting Makefile variables
|
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
configure
The configure
script recognizes the following options
to control how it operates.
Set the common prefix for installation directories to directory. The prefix is set to ‘/usr/local’ unless this option is specified.
Tell the configure
script where the source code for this package resides.
Usually you do not have to specify this option,
for the configure
script automatically guesses the source directory
based on how it is invoked.
For example,
if you invoke the configure
script by typing ‘./configure’,
the source directory is set to ‘.’.
Forbid the garbage collector to scan data segments associated with dynamic libraries. This option is mandatory if you use rather old SunOS (3.x or 4.0.x).
Use BSD byte operations such as bcopy
and bcmp
,
even if standard memory operations such as memcpy
and memcmp
are available.
(On NEWS-OS 4.2R,
memcpy
is much slower than bcopy
.)
Use the installed CLU2C system to compile CLU source files. You should not specify this option unless CLU2C is already installed.
Use getwd
to get current working directory
even if getcwd
is available.
(On SunOS 3.x and 4.x,
getcwd
invokes pwd
.)
Declare that you will use the GNU assembler. Currently this option has an effect on Sony CISC NEWS only.
Set the default coding system for file input to coding-system. It is set to ‘autoconv’ unless this option is specified.
Set the default coding system for file output to coding-system. It is set to ‘iso-2022-jp’ unless this option is specified.
The ‘--with-input-code’ and ‘--with-output-code’ options accept the following names as a specification for coding systems.
No code conversion is performed. A file is treated as a byte sequence.
Japanese EUC.
Shift JIS.
ISO-2022-JP. See Japanese Character Encoding for Internet Messages (RFC 1468), for more detail about this coding system.
Guess the coding system automatically. This can be specified only as an input coding system.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You can control values of some ‘Makefile’ variables
via environment variables.
The preset value precedes the value configure
guesses.
For example,
if you want to use cc
for the C compiler,
you can achieve it
by setting the CC
environment variable to cc
prior to running configure
.
If you use the Bourne shell or its descendant,
you can do like the following:
CC=cc ./configure
Or,
if you have the env
program,
you can do like the following:
env CC=cc ./configure
The following Makefile variables can be preset in such a way.
Typical values that configure
guesses are in square brackets.
CC
C compiler.
[gcc
or cc
]
CFLAGS
Default options to the C compiler.
[-O -g
for gcc
, -g
for other C compilers]
AS
Assembler.
[as
]
LIBS
Additional libraries for linking program.
[-lm
]
LDFLAGS
Additional options to the C compiler for linking. [(empty)]
AR
Archive and library maintainer.
[ar
]
ARFLAGS
Default flags to ar
.
[ru
]
RANLIB
Library randomizer.
[ranlib
or :
]
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
There are two choices for installing CLU2C on MS-DOS systems. Probably most users would like to get a binary distribution package and install it, without compiling any source code. On the other hand, you may want to get a source distribution package and begin the installation process by compiling source code. In either case, you need to install DJGPP prior to the installation of CLU2C.
A.3.1 Requirements | You need DJGPP | |
A.3.2 Installing from Binary Distribution Package | Easier way | |
A.3.3 Installing from Source Distribution Package | Rather hard way |
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
CLU2C on MS-DOS systems requires DJGPP Version 2 (or later) to be installed. DJGPP is available via anonymous FTP from SimTel mirror sites. At the minimum, you need to get the following files.
See the file ‘v2/readme.1st’ for more detail about DJGPP.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This subsection shows instructions for installing CLU2C on MS-DOS systems from a binary distribution package.
gcc
works fine.
mkdir c:\clu2c
c: cd \clu2c
lha x somewhere\clu200b.lzh
or
unzip somewhere\clu200b.zip
CLU2CROOT
environment variable
to point to the installation directory.
For example,
if you have chosen ‘c:\local\clu2c’ as an installation directory,
put the line
set CLU2CROOT=c:\local\clu2c
into your ‘autoexec.bat’.
set PATH=c:\clu2c\bin;%PATH%
into your ‘autoexec.bat’.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This subsection shows instructions for installing CLU2C on MS-DOS systems from a source distribution package. We assume that you have unpacked the source distribution package and are at the top source directory.
gcc
, ar
, and ranlib
work fine.
make
program you will use to build CLU2C
is invoked by simply saying ‘make’.
configure
script for UNIX systems,
however,
‘configure.bat’ does not guess system-dependent parameters.
Instead,
it merely copies configuration files from the ‘config’ directory.
CLU2CROOT
environment variable (if necessary)
and the command search path,
as in installing from binary distribution package.
We have found the difficulty of writing general makefiles for MS-DOS systems. In your environment, things might not go well as described above. We expect some effort on your side.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This section shows instructions to compile CLU2C in a separate directory.
make
program you use has a VPATH
feature.
configure
script in the source directory
if you have not run.
configure
script.
Now you can compile in the build directory. Type ‘make’ to compile the entire package; Type ‘make install’ to install the resulting products.
For example, if you have unpacked the distribution package into ‘/usr/local/src/clu2c-2.0’ and want to do compilation in the ‘/usr/local/src/clu2c-2.0/build’, command lines you type might look like this:
cd /usr/local/src/clu2c-2.0 ./configure make mostlyclean cfiles mkdir build cd build ../configure make
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Here is the list of common targets that are defined in ‘Makefile’ in almost every directory. These targets are applied to the current directory and all its subdirectories recursively.
Compile the entire source files. This is the default target.
Compile the entire source files and copy the resulting products to the file names where they should reside for actual use.
Remove all the files that are created by running make
.
Remove almost all the files that are created by running make
but do not remove C files that are translated directly or indirectly
from CLU source files.
Remove all the files
that are created by running configure
and make
.
If you did not create any other files,
‘make distclean’ restore the source tree to its original contents.
Recreate ‘Makefile’. You have to make this target whenever you modify the file ‘config.mk’ manually.
Prepare C source files that are translated directly or indirectly
from CLU source files.
Some make
programs fail to follow the chain of suffix rules.
Particularly,
they understand that ‘foo.o’ is to be made from ‘foo.c’
but cannot think of this C source file being made from ‘foo.clu’.
In this case,
you have to ‘make cfiles’ first before you ‘make all’.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Every ‘Makefile’ is actually a concatenation of three files:
This file resides in each directory,
and contains variable definitions
that may vary dependent on how the configure
script is invoked
and are specific to each directory.
VPATH
, srcdir
, and top_srcdir
are defined here.
This file is created automatically by running the configure
script.
This file resides in the top build directory,
and contains variable definitions
that may vary dependent on how the configure
script is invoked
and can be shared by all the ‘Makefile’.
This file is created automatically by running the configure
script.
One of these files constitute the rest of ‘Makefile’. These files reside in each directory, and contains variable and rule definitions that are specific to each directory and should not be modified. These files are included in the source distribution package.
In every directory there is a file named ‘Makefile.in’. This file
is processed by the m4
macro processor to generate
‘Makefile.unix’ and ‘Makefile.dos’.
Note that these files are included in the distribution package and you
do not have to prepare the m4
macro processor in order to compile
CLU2C.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The source and binary distribution packages of the latest version of CLU2C
is available via anonymous FTP
from the host ftp.is.titech.ac.jp
at the directory ‘pub/clu2c’.
The following files are placed at that directory.
Source distribution packages for UNIX systems. These are gzipped tar files.
Source distribution packages for MS-DOS systems.
These are archive files archived by lha
or zip
.
Binary distribution packages for MS-DOS systems.
These are archive files archived by lha
or zip
.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following are the terms and conditions for copying, modifying, and distributing CLU2C.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Jump to: | ?
A B C D E F G H I K L M N O P Q S T U W X |
---|
Jump to: | ?
A B C D E F G H I K L M N O P Q S T U W X |
---|
[Top] | [Contents] | [Index] | [ ? ] |
On MS-DOS systems,
the clulink
program further creates ‘a.exe’ from ‘a.out’.
[Top] | [Contents] | [Index] | [ ? ] |
[Top] | [Contents] | [Index] | [ ? ] |
This document was generated on September 9, 2012 using texi2html 5.0.
The buttons in the navigation panels have the following meaning:
Button | Name | Go to | From 1.2.3 go to |
---|---|---|---|
[ << ] | FastBack | Beginning of this chapter or previous chapter | 1 |
[ < ] | Back | Previous section in reading order | 1.2.2 |
[ Up ] | Up | Up section | 1.2 |
[ > ] | Forward | Next section in reading order | 1.2.4 |
[ >> ] | FastForward | Next chapter | 2 |
[Top] | Top | Cover (top) of document | |
[Contents] | Contents | Table of contents | |
[Index] | Index | Index | |
[ ? ] | About | About (help) |
where the Example assumes that the current position is at Subsubsection One-Two-Three of a document of the following structure:
This document was generated on September 9, 2012 using texi2html 5.0.