Tuesday, July 10, 2007

CVS import


cvsimport The way you create a new directory or tree of directories in
You use a cvs import command when you want to add a whole directory to
CVS. CVS import is not used to add a bunch of files to an existing
directory - for that use "cvs add" (see above). Before getting into the
command itself, first pick a place in the existing cvs tree where you
want to add your stuff. For this example, let's say you wanted to add a
directory of "tool" files to cvs at the new directory "common/tool", so
its reference directory would be $CD_SOFT/ref/common/tool/. The argument
you would have to give to the cvs import command will be "common/tool".
The argument is always the full pathname, after the $CD_SOFT/cvs part,
of the root of the directory you want to create, even if some of the
intermediate directories already exist (in this case, "common/" already

cvs import always imports all the files, and all subdirectories, in the
working directoryfrom which it is being run. That is, it imports a
directory tree into the place specified by the argumetk. So, be careful
not to do something like cd to a directory which contains the root of a
directory tree which you want to import and then issue cvs import giving
as the argument the leaf-of-directory-tree you want to import, e.g. cd
~/work (containing common/tool) and then cvs import common/to.ol. That
would create $CD_SOFT/cvs/common/tool/common/tool/!! If you only want to
import a single directory, then the root and the leaf are the same
directory, so you can use a sequence of commands as in example 1) below.
But if you really want to import more than one directory, you have to
use a sequence like that in example 2.

Also be careful not to import a directory system that contains a
subdirectory that is itself the result of a CVS checkout, because that
subdirectory will contain a CVS subdirectory. This is very messy to
clean up. You shouldn't ever want to anyway, because cvs import must
always be run from the directory whose files you want to import, and
always takes the fully qualified cvs module name as the argument.

The two other arguments to cvs import are the "vendor tag", and the
"release" tag:

* "vendor tag" is a free form text string you're supposed to use
to identify the vendor of software. Since it's a CVS tag, it
should be all upper case and not have any special charatcters
save the "_" (like no "." or "-"). Our standard for this tag is
"CD_SOFT", when we're the vendors.
* "release tag", is also a free form text string you're supposed
to use to identify the release of the software you're putting in
CVS. For EPICS software, we use a release tag like "R3_13_6",
for all other software, for the initial release, we use "R1_0".

After you have done the cvs import, be sure to go to the corresponding
reference area and do the initial cvs checkout.


cvs import [options]
vendor-tag release-tag


cd ~/work/common/tool

cvs import common/tool

cd $CD_SOFT/ref

cvs checkout common/tool

Say ~/work/common/tool
is the directory where
all the tool files are.
All the files in that
directory will be
imported (unless they're
in the CVSIGNORE set).

Imports all the files
from your working
directory, into

Creates the initial
checkout of the
directory you just
created in cvs.


cd ~/work

cvs import app/myapp

cd $CD_SOFT/ref

cvs checkout app/myapp

Say ~/work is the root
directory of where all
the files are of a new
application are. All the
files and all the
subdirectories in that
directory will be
imported into
cvs/app/myapp (unless
they're in the CVSIGNORE

Imports all the files
from ~/work, into


cvs import -m "initial
import" ... app/myapp

As above, but gave a
comment on the command
line rather than making
cvs start an editor and
asking for the comment

Monday, July 09, 2007

Gnu-make: define virables

There are two ways that a variable in GNU make can have a value; we call
them the two flavors of variables. The two flavors are distinguished in
how they are defined and in what they do when expanded.

The first flavor of variable is a recursively expanded variable.
Variables of this sort are defined by lines using `=' (see section
Setting Variables) or by the define directive (see section Defining
Variables Verbatim). The value you specify is installed verbatim; if it
contains references to other variables, these references are expanded
whenever this variable is substituted (in the course of expanding some
other string). When this happens, it is called recursive expansion.

For example,

foo = $(bar)
bar = $(ugh)
ugh = Huh?

all:;echo $(foo)

will echo `Huh?': `$(foo)' expands to `$(bar)' which expands to `$(ugh)'
which finally expands to `Huh?'.

This flavor of variable is the only sort supported by other versions of
make. It has its advantages and its disadvantages. An advantage (most
would say) is that:

CFLAGS = $(include_dirs) -O
include_dirs = -Ifoo -Ibar

will do what was intended: when `CFLAGS' is expanded in a command, it
will expand to `-Ifoo -Ibar -O'. A major disadvantage is that you cannot
append something on the end of a variable, as in


because it will cause an infinite loop in the variable expansion.
(Actually make detects the infinite loop and reports an error.)

Another disadvantage is that any functions (see section Functions for
Transforming Text) referenced in the definition will be executed every
time the variable is expanded. This makes make run slower; worse, it
causes the wildcard and shell functions to give unpredictable results
because you cannot easily control when they are called, or even how many

To avoid all the problems and inconveniences of recursively expanded
variables, there is another flavor: simply expanded variables.

Simply expanded variables are defined by lines using `:=' (see
section Setting Variables). The value of a simply expanded variable is
scanned once and for all, expanding any references to other variables
and functions, when the variable is defined. The actual value of the
simply expanded variable is the result of expanding the text that you
write. It does not contain any references to other variables; it
contains their values as of the time this variable was defined.

x := foo
y := $(x) bar
x := later

is equivalent to

y := foo bar
x := later

When a simply expanded variable is referenced, its value is substituted

GNU-Make: Variables from the Environment

Variables from the Environment
Variables in make can come from the environment in which make is run.
Every environment variable that make sees when it starts up is
transformed into a make variable with the same name and value. But an
explicit assignment in the makefile, or with a command argument,
overrides the environment. (If the `-e' flag is specified, then values
from the environment override assignments in the makefile. See section
Summary of Options. But this is not recommended practice.)

Thus, by setting the variable CFLAGS in your environment, you can cause
all C compilations in most makefiles to use the compiler switches you
prefer. This is safe for variables with standard or conventional
meanings because you know that no makefile will use them for other
things. (But this is not totally reliable; some makefiles set CFLAGS
explicitly and therefore are not affected by the value in the

When make is invoked recursively, variables defined in the outer
invocation can be passed to inner invocations through the environment
(see section Recursive Use of make). By default, only variables that
came from the environment or the command line are passed to recursive
invocations. You can use the export directive to pass other variables.
See section Communicating Variables to a Sub-make, for full details.

Blog Archive