requirements ">
]>
This environment, based on some management conventions and
comprising several utilities, is an attempt to
formalize software production and especially configuration
management around a package-oriented principle. The notion of packages represents hereafter a set of
software components (that may be applications, libraries,
documents, tools etc...) that are to be used for producing a
system or a framework. In such an environment,
several persons are assumed to participate in the development and
the components themselves are either independent or related to
each other. The environment provides conventions (for naming
packages, files, directories and for addressing them) and
tools for automating as much as possible the implementation
of these conventions. It permits the description of the
configuration requirements and automatically deduce from the
description the effective set of configuration parameters needed
to operate the packages (typically for building them or
using them). CMT lays upon some organisational or managerial
principles or mechanisms described below. However, it permits in
many respects the users or the managers to control,
specialize and customize these mechanisms, through
parameterization, strategy control and generic specifications.
Following these definitions, the basic configuration management operations involved here (and serviced by the CMT tools) consist of :
This environment relies on a set of conventions, mainly for organizing the directories where projects and packages are maintained and developed :
or (obsolescent convention)
The <version mnemonic> directory level may also be omitted, in which case the version information will be stored inside the cmt directory in a conventional file named version.cmt leading to the following alternate organization:
In both cases, the cmt directory holds the main source of information needed by CMT: the requirements file. All CMT-related operations are generally executed from this directory.
This style of organization should be considered as the basic (and unique) criterion for a package to be recognized as a valid CMT package. Any other structuring convention will be supported by CMT and its operations can always be customized to follow them
This structure is a central concept since all relationships between packages relies on the package identification which unambiguously and exclusively consists in the duet [ package-name, package-version ] (or package-name only when the version directory level is omitted).
Many other parallel directory branches (similar to cmt) such as src, include or test may be freely added to this list according to the specific needs of each package. In particular, a set of such parallel branches are expected to contain binary outputs (those that compilers, linkers, archive managers or other kinds of code or pseudo-code generators can produce). Their name always corresponds to the particular configuration tag used to produce the output (such as the machine or operating system type). The CMT toolkit provides, through the cmt system utility, a default value for this token. An environment variable (CMTCONFIG) is also assigned to this value (See the complete description of configuration tags).
Each branch may in addition be freely structured, and there is no constraint to the complexity of this organization.
A software base is generally composed of multiple coherent sets of packages, each installed in its specific root directory and forming different package areas or sub-projects
Package areas implement the concept of projects or sub-projects which correspond to the practical organization of the software base.
There are no constraints on the number of such sub-projects or areas into which CMT packages are installed. We'll see later how the different sub-projects can be declared and identified by CMT.
examples of such organization can be :
This environment is based on the fact that one of its packages (named CMT) provides the basic management tools. CMT, as a package, has very little specificities and as such itself obeys the general conventions.
Then the complete software base is organized in terms of projects (or sub-projects), containing consistently managed package sets. Projects are localized either globally or individually:
It should be noted that the choice of a location for installing CMT itself is totally independent of the locations where projects are installed and managed.
CMT is operated through one main user interface : the cmt command, which operates the CMT conventions and which provides a set of services for :
Several other utilities are also provided for some specific activities (such as the automatic production of shared libraries, C prototypes, management of interactions between CVS and CMT itself, the management of a similar architecture for Windows or OS9, setting up protections for packages (through locks) etc...).
In the CMT terminology, the complete software base is composed of CMT packages. Those packages are organized into sub-projects. The semantics of a sub-project is very opened since it's merely an area for grouping CMT packages. Typically sub-projects may correspond to
Considering the simple structuring aspects of sub-projects, two important configuration parameters (environment variables) handled by CMT must be understood before attempting to manage packages:
Projects receive detailed descriptions or specifications in a dedicated project file, always located in a cmt directory at their top directory level, and named cmt/project.cmt. It can receive the following specifications:
By default a project inherits the strategies of its parents. Or if it's the top project, it follows the default strategies defined by CMT (Refer to this appendix to see the default strategies currently defined by CMT).
The project file can be created using the command:
This will create the complete directory hierarchy from the current directory (or, when it is specified from the optional project path). It will also create a project file containing the project name, and optionnally will initialize it with some use statements.
Note that the <release> argument may be left empty (or to an empty string). In this case, the directory hierarchy will be limited to the single level of the project name.
As an example, we create the following projects:
And we manually fill CMTPATH with:
Then, when standing in the WorkArea the following projects will appear displayed from bottom to top as
Of course the preferred way to characterize this software base should rather be based on specifying the relationships between those three sub-projects, through the use statements in the projects files.
For instance in our little example, we could add the following statement into the project file of WorkArea:
and the following statement into the project file of ProjectB:
Then instead of specifying CMTPATH we'd rather simply define CMTPROJECTPATH as:
This complete sequence may also be shortened as follows:
Few behaviours of the configuration management process can be tailored with respect to CMT, via means of defining strategies. Then according to these strategies, CMT will behave in well defined ways.
Every strategy setting is a boolean value, instructing CMT to activate or not a given behaviour. As such it defines two mutually exclusive CMT tags and it activates one of them.
Examples
In the context of a hierarchy - a graph - of projects, strategies are transmitted along the graph, according to the use relationships specified between the projects. A project transmits its strategies to its clients except when one of them overrides those strategies.
Several mechanisms help defining project specific properties, and more specifically making use of the strategies:
This is an environment variable containing a search list, very similar to the well know Unix or Windows PATH environment variable. It specifies a list of file paths where CMT projects can be found. The syntax of this search list follows the standard syntax of search lists, i.e. items are separated using a : character on Unix and a ; character on Windows.
One should understand this search list as the primary mechanism to locate sub-projects in the software base, and therefore packages. This in particular can completely replace the CMTPATH-based search mechanism for packages that was used before v1r18. However the two mechanisms are still both supported and in fact interact with each other.
A sub-project in itself is a multi-level directory structure, located below one of the items of this search list, and composed of:
Then, below this directory structure, we find
A typical example of such a structure could be:
In this example:
This search list is used to interpret the use statements written in the project files. This project use statement takes the form:
Typically, in our example one could construct the project file of the Reconstruction sub-project as follows:
Note that sub-project release identifiers are always considered using a perfect-match principle.
Structuring the set of sub-projects comprising a software base is sufficient to permit CMT to find all sub-projects and thus all packages in them. Defining CMTPROJECTPATH and installing the list of use statements in all appropriate project files entirely suppress the need of manually defining the CMTPATH search list.
This is an environment variable containing a search list, very similar to the well know PATH environment variable, containing a list of file paths where CMT packages can be found. The syntax of this search list follows the standard syntax of search lists, i.e. items are separated using a : character on Unix and a ; character on Windows.
When the software base is organized and configured using the CMTPROJECTPATH search list and project-use statements in the project files, this search list is automatically and internally generated by CMT, and therefore it should not be manually defined nor manipulated. If this is your case, you can skip this section
It is possible to manually define this search list (when CMTPROJECTPATH is not defined or when project files are not provided)
There should be one entry per package area, and the list is ordered. The order of items is used to prioritize the package search.
CMTPATH can be specified:
The project file (i.e. the file cmt/project.cmt), when it exists for the current package (i.e. upstream in the directory hierarchy), also provides an automatic value for the CMTPATH search list.
We consider here the installation of a user package. Installing CMT itself requires special attention and is described in a dedicated section of this document.
Therefore, we assume that CMT is already installed in some location in the system. One first has to setup CMT in order to gain access to the various management utilities, using for example the shell command:
Obviously, this operation must be performed (once) before any other CMT action. Therefore it is often recommended to install this setup action straight in the login script.
The setup script used in this example is a constant in the CMT environment : every configured package will have one such setup script automatically generated and installed by CMT. It is one important entry point to any package (and thus to CMT itself). It provides environment variable definitions for all related (used) packages (A corresponding cleanup script is also provided). This script contains a uniform mechanism for interpreting the &CMTrequirements; file so as to dynamically define environment variables, aliases for the package itself and all its used packages. It is constructed once per package installation by the cmt create command, or restored by the cmt config command (if it has been lost).
It is generally good to start by immediately defining a project. This project is our first disk area where CMT packages will be located. Remember that several such projects can be set up and defined. The simplest way to do this is:
This creates a project structure Dev/cmt/project.cmt from the current directory. Once this project has been created we have a complete environment to start creating packages below Dev and working out our software base.
A package is primarily defined by a name and a version identifier (this duet actually forms the complete package identifier). These two attributes will be given as arguments to cmt create such as in the following example :
The package creation occured from the current directory, creating from there the complete directory tree for this new package.
In the next example, we install the package in a completely different area, by explicitly specifying the path to it as a third argument to cmt create :
The FOOROOT and FOOCONFIG environment variables are defined automatically by this operation.
It should be noted that running the setup script of a package is not always necessary for building operations. The only situation where running this script may become useful, is when an application is to be run, while requiring domain specific environment variables defined in one of the used packages. Besides this particular situation, running the setup scripts may not be needed at all.
Lastly, this newly created package may be removed by the quite similar remove command, using exactly the same arguments as those used for creating the package.
So far our package is not very useful since no constituent (application or library) is installed yet. You can jump to the section showing how to work on an application or on a library for details on these operations or we can roughly draw the sequence used to specify and build the simplest application we can think of as follows:
Directly running the application is possible since the application has been installed after being built in an automatic installation area reachable through the standard PATH environment variable
This can also be integrated in the build process by providing the -check option to the application definition:
In the next sections, we'll see that packages reference each other by means of use relationships. Generally packages are found in different locations, according to the project - or sub-project - they belong to. CMT provides a quite flexible mechanism for localizing the referenced packages.
The first ingredient we need at this level is to understand how projects themselves are localized, since packages will be found inside project areas. You should therefore refer to the section on projects where the complete mechanism based on CMTPROJECTPATH or CMTPATH is described.
However, there is one special case where this path list can be avoided, i.e. when only one project is considered. In this case, the knowledge of this single project area can simply be deduced from the detection of the project file, created at the top of its disk space.
A given version of a given package is always referred to by using a use statement within its &CMTrequirements; file. This statement should specify the package through three keys :
Given these keys, the referenced package is looked for according to a prioritized search list which is (in decreasing priority order) :
If the path argument is specified as a relative path (case #2 above) (ie. there is no leading slash character or it's not a disk on windows machines), it will be used as an offset to each search case. The search is done starting from the list specified in the CMTPATH configuration parameter; and the offset is appended at each searched location.
As an example, if the CMTPATH parameter contains:
Then a use statement (defined within a given package) containing :
The actual complete search list can always be visualized by
the command:
A typical package of that kind will contain:
The requirements file will generally contain at least library and application statements.
The basic contents of such a package is the requirements file including
In principle the idea when such a policy package is defined, is that all packages of the project or of the sub-project will use it
Global patterns may be specified so as to automate the applying of basic policies and conventions.
Typical examples of policies that are profitably specified in such a package are:
In large projects, it is even often desirable to split the policies into a set of specialized policies and to associate one dedicated policy package with each of those.
Management activities directly related with the associated sub-domain can then be undertaken through this special package:
Generally the use statements installed in a container package make use of explicit version specification (and prohibit wild carding) since each version of this container package acts as a reference of the set of version tags validated for the packages of the domain.
The primary goal fo such a glue package is to convert the management conventions and policies expected by the referenced product to the ones appropriate for the current project.
Generally this kind of package only provides a requirements file, or make fragments used to automate some actions (typically when document generation is expected from thie interfaced product)
Software bases managed by CMT are often replicated to multiple geographically distant sites (as opposed to machines connected through AFS-like WAN). In this kind of situation, some of the configuration parameters (generally those used for instance to reference local installations of external software) take different values.
The CMTSITE environment variable or registry in Windows environments, is entirely under the control of the site manager and can be set with a value representing the site (typical values may be LAL, Virgo, Atlas, LHCb, CERN, etc.).
This variable, when set, corresponds to a tag which can be used to select different values for make macros or environment variables.
A typical use for this tag is to build up actual values for the location path of an external software package. Here we take the example of the Anaphe utility:
The first ingredient of a proper package configuration is the set of configuration parameters which has to be specified in a text file uniquely named &CMTrequirements; and necessarily installed in the cmt branch of the package directory tree.
An empty version of this file is automatically created the first time the package is installed, and the package manager is expected to augment it with configuration specifications.
The primary goal of this configuration file is to specify any configuration information for this package. There is virtually no limit to what could be specified there. And we can expect to find exhaustive information about:
Many configuration parameters are supposed to be described into this &CMTrequirements; file - see the detailed syntax specifications here - namely :
Generally, every such appropriate parameter will be deduced on demand from the &CMTrequirements; file(s) through the various query functions available from the cmt main driver. Therefore there is no systematic package re-configuration per se, besides the very first time a package is newly installed in its location (using the cmt create action).
Query actions (generally provided using the cmt show ... family of commands) are to be embedded in the various productivity tools, such as the setup shell scripts, or makefile fragment generators.
These query actions always interpret the set of &CMTrequirements; files obtained from the current package and from the packages in the effective used chain. Symbols, tags and other definitions are then computed and built up according to inheritance-like mechanisms set up between used packages.
Conversely one may say that parameters defined in a &CMTrequirements; file are meant to be exported to the clients of the package.
Other configuration parameters are also optionally inserted from the HOME and USER context requirements files
Typical examples of these query functions are:
CMT relies on several complementary conventions or mechanisms for this description and the associated management. All these conventions rely on the concept of configuration tags.
This script automatically builds a value characterizing both the machine type and the opebrating system type (using a mixing of the uname standard UNIX command with various operating system specific definitions such as the AFS based fs sysname command)
For instance, a package defines a library A and an application P, both in the default group. Both constituents have their -target_tag option set. Thus, when the standard make command is run, then those two targets will be rebuilt successively (eg A then B). Then, during the build of A (and only then) the tag named target_A will be active and during the build of B, the tag named target_Bwill in turn be active.
The user configuration tags can generally be specified though various complementary mechanisms:
The tag associated with the current project name as well as those describing the strategy properties of all projects are also always active.
The target tags associated with constituents (when the -target_tag option was set on them) or with actions are automatically activated during the build of the constituent or during the execution of the action.
It is possible to activate other tags through the following arguments to any cmt command:
will cleanup the complete current tag set, and activate the new tags (the system tags are restored).
will add to the current tag set the tags specified in the comma separated list
will remove from the current tag set the tags specified in the comma separated list
However it's often useful to state that a given tag or tag set should be active. This can be obtained by the following mechanisms:
The current active tag set can always be visualized using the cmt show tags command.
Typical usages of those extra tags are:
All symbol definitions providing specific values triggered by the active selectors will be selected, such as in:
In this section, we'll see, through a quite simple scenario, the typical operations generally needed for installing, defining and building a package. We are continuing the example of the Foo package already used in this document.
Let's assume, as a first example, that the Foo package is originally composed of one library libFoo.a itself made from two sources : FooA.c and FooB.c. A shared flavour of the library libFoo.so or libFoo.sl or libFoo.dll) is also foreseen.
The minimal set of branches provided by CMT (once the cmt create operation has been performed) for a package includes src for the sources and cmt for the Makefiles and other scripts.
The various tools CMT provide will be fully exploited if one respects the roles these branches have to play. However it is always possible to extend the default understanding CMT gets on the package by appropriate modifiers (typically by overriding standard macros).
Assuming the conventional usage is selected, the steps described in this section can be undertaken in order to actually develop a software package.
We first have to create the two source files into the src branch (typically using our favourite text editor). Then a description of the expected library (ie. built from these two source files) will be entered into the requirements file. The minimal syntax required in our example will be :
The cmt create command had generated a simple Makefile (or NMake file) which is generaly sufficient for all standard operations, since CMT continuously and transparently manages the automatic reconstruction of all intermediate makefile fragments. We therefore simply and immediately execute gmake as follows:
This mechanism relies on some conventional macros and incremental targets used within the specific makefiles. Some are automatically generated, some have to be specified in user packages. It's quite important to understand the list of possible customization macros, since this is the main communication medium between CMT and the package manager. See the complete table of those conventional macro when you want to interact with the standard CMT behaviour.
However, it is also possibble to use a simplified and platform independent form to build a constituent
This syntax is identical on all platforms, and also does not require any cmt config nor source setup operation
Assume we now want to add a test program to our development. Then we create a FooTest.cxx source, and generate the associated makefile (specifying that it will be an executable instead of a library) :
The Foo_linkopts conventional macro will be automatically inserted within the use_linkopts macro. And the shared library location will be automatically set to the installation areas.
It is also possible to select extra tag sets when running gmake as follows (in this example we first cleanup the previous build and rebuild with debug options added to the compiler and linker commands) :
Like all other make macros used to build a component, the Foo_linkopts will be specified within the &CMTrequirements; which gives several benefits:
Here, no special convention is assumed on the location of the sources, the binaries, the management scripts, etc... However, it is possible to describe in a &CMTrequirements; file the use relationships, as well as the make macro definitions, quite similarly to the package entirely configured using CMT.
Most of the options provided by the cmt user interface are still available in these conditions.
In a Unix environment, documents are built using make (well generally its gnu flavour) or nmake in Windows environments. The basic mechanism provided in CMT relies on make fragment patterns containing instructions on how to rebuild document pieces. Many such generators are provided by CMT itself so as to take care of of the most usual cases (e.g. compilations, link operations, archive manipulations, etc...). In addition to those, any package has to possibility to provide a new generator for its own purpose, i.e. either for providing rules for a special kind of document, or even to override the default ones provided by CMT. This mechanism is very similar to the definition or re-definition of macros or environment variables in that every new generator has to be first declared in a &CMTrequirements; file belonging to a package (CMT actually declares all its default generators within its &CMTrequirements; file), allowing all its client packages to transparently acquire the capacity to generate documents of that sort.
CMT manages two categories of constituents:
In this section we only discuss the latter category and the following paragraphs explain the framework used for defining new document types.
The main concept of this framework is that each document to be generated or manipulated must be associated with a "document-type" (also sometimes named "document-style"), which corresponds to a dedicated make fragment of that name. Then, when specified in a document statement, this make fragment will be instanciated once or several times (typically once per source file) to construct a complete and functional make fragment, containing one main target. Both the resulting make fragment and the make target will have the name of the constituent.
Converting a latex source file into a postcript output implies to chain two text processors, with an intermediate dvi format.
The fragment described here exactly performs this sequence, taking care of intermediate file deletion. The document style is named "tex" (the associated fragment shown here and named "tex" is actually provided by CMT itself, and can be looked at in ${CMTROOT}/fragments/tex.) :
The result for our example is:
-suffix=<suffix> | provide the suffix of the output files (without the dot) |
-header=<header> | provide another make fragment meant to be prepended to the constituent's make fragment. |
-trailer=<trailer> | provide another make fragment meant to be appended to the constituent's make fragment. |
-dependencies | install the automatic generation of dependencies into the constituent's make fragment |
Once a fragment is installed and declared, it may be used by any client package (ie a package using the provider), and queried upon using the command
which will show where this fragment is defined (ie. in which of the used packages).
The cmt show fragments commands lists all declared fragments.
If a package re-defines an already declared make fragment, ie it provides a new copy of the fragment (possibly with new copies of the header and the trailer), and declares it inside its requirements file, then this package becomes the new provider for the document style.
For building a fragment, one may use pre-defined generic "templates" (which will be substituted when a fragment is copied into the final constituent's makefile).
CONSTITUENT | the constituent name |
CONSTITUENTSUFFIX | the optional constituent's output suffix |
FULLNAME | the full source path name (including directory and suffix) |
FILENAME | the complete source file name (only including the suffix) |
NAME | the short source file name (without directory and suffix) |
FILEPATH | the source directory |
SUFFIX | the suffix provided in the -suffix option |
OBJS | (only available in headers) the list of
outputs, formed by a set of expressions :
|
Templates must be enclosed between ${ and } or between $( and ) and will be substituted at the generation time. Thus, if a fragment contains the following text :
then, the expanded constituent's makefile will contain (refering to the "tex" example)
Which shows that make macros may be dynamically generated.
It generates C++ hubs for the Cint interpreter in Root.
It generates C++ source files (xxx.g files) from Atlas' AGE description files.
The sections below will detail the complete syntax of the &CMTrequirements; file since it is the basis of most information required to run the tools as well as the main commands available through the cmt user interface.
Statements generally occupy one single line, but may be split into several lines using the reverse-slash character (in this case the reverse-slash character must be the last character on the line or must be only followed by space characters).
Each statement is composed of words separated with spaces or tabulations.
The first word of a statement is the name of the configuration parameter.
The rest of the statement provides the value assigned to the configuration parameter.
Words composing a statement are separated with space or tab characters. They may also be enclosed in quotes when they have to include space or tab characters. Single or double quotes may be freely used, as long as the same type of quote is used on both sides of the word.
Special characters (tabs, carriage-return and line-feed) may be inserted into the statements using an XML-based convention:
tabulation | <cmt:tab/> |
carriage-return | <cmt:cr/> |
line-feed | <cmt:lf/> |
Comments : they start with the # character and extend up to the end of the current line.
Packages are installed in a directory structure that can optionnally include a version directory (just after the top directory of the package name). This is controlled through the structuring style or structuring strategy parameters specified using one of the following means:
It should be noted that the command line option will take precedence over the strategy specification, in case of conflict.
Describe the composition of a constituent. Application and library correspond to the standard meaning of an application (an executable) and a library, while document provides for a quite generic and open mechanism for describing any type of document that can be generated from sources.
Applications and libraries are assigned a name (which will correspond to a generated make fragment, and a dedicated make target).
A document is first associated with a document type (which must correspond to a previously declared make fragment). The document name is then used to name a dedicated make fragment and a make target.
Various options can be used when declaring a constituent:
-s=directory | any | switch to a new default directory (1) |
-x=regexp | any | specify an exclusion regular expression to be applied to the sources (1) |
-k=regexp | any | specify a finer selection regular expression to be applied to the sources (1) |
-no_share | libraries | do not generate the shared library |
-no_static | libraries | do not generate the static library (not yet implemented) |
-prototypes | applications, libraries | do generate the prototype header files |
-no_prototypes | applications, libraries | do not generate the prototype header files |
-check | applications | generate a check target meant to execute the rebuilt application |
-group=<group-name> | any | install the constituent within this group target |
-suffix=<suffix> | applications, libraries | provide a suffix to names of all object files generated for this constituent (2) |
-import=<package> | applications, libraries | explicitly import for this constituent the standard macros from a package that has the -no_auto_imports option set |
-target_tag | any | construct a specific tag named target_<constituent>. This tag will only be active during the make session for this constituent. (4) |
-windows | applications | When used in a Windows environment, generates a GUI-based application (rather than a console application) |
<var-name>=<var-value> | any | define a variable and its value to be given to the make fragment (3) |
The sources of the constituents are generally specified as a set of file names with their suffixes, and are by default expected from the ../src directory
Then it is possible to change the default search location as well as to use a simplified wildcarding syntax:
It's also possible to select or exclude files using regular expressions from general wildcarding techniques:
When several constituents need to share source files, (a typical example is for building different libraries from the same sources but with different compiler options), it is possible to specify an optional output suffix with the -suffix=<suffix> option. With this option, every object file name will be automatically suffixed by the character string "<suffix>", avoiding name conflicts between the different targets, as in the following example:
It's possible to specify in the list of parameters one or more pairs of variable-name=variable-value (without any space characters around the "=" character), such as in the next example:
For any constituent that has the -target_tag option set, a dedicated tag named target_<constituent> is automatically constructed by CMT. This tag becomes active during the construction of this constituent when using make, and therefore can be used as any other tag to select symbol values, or other configuration parameters.
Each group is associated with a make target (of the same name) which, when used in the make command, selectively rebuilds all constituents of this group.
The default group (into which all constituents are installed by default) is named all, therefore, running make without argument, activates the default target (ie. all).
As a typical usage of this mechanism, one may examplify the case in which one or several constituents are making use of one special facility (such as a database service, real-time features, graphical libraries) and therefore might require a controled re-build. This is especially useful for having these constituents only rebuilt on demand rather than rebuilt automatically when the default make command is run.
One could, for instance specify within the requirements file :
Then, running gmake all would only rebuild the un-grouped constituents, whereas running
in the context of the Foo package would rebuild objy related or graphics related constituents.
We consider here languages that are able to produce object files from sources.
Let's take an example. We would like to install support for Fortran90. We first have to declare this new language support to CMT within the requirements file of one of our packages (Notice that it's not at all required to modify CMT itself since all clients of the selected package will inherit the knowledge of this language).
The language support is simply named fortran90 and is declared by the following statement:
The language support being named fortran90, two associated make fragments are expected, one under the name fortran90 (for building application modules), the other with the name fortran90_library (for modules meant to be archived), both without extension.
These two fragments should be installed in the fragments sub-directory of the cmt branch of our package.
Due to the similarity of the example to fortran77, we may easily provide the expected fragments simply by copying the f77 fragments found in CMT (thus the fragments ${CMTROOT}/fragments/fortran and ${CMTROOT}/fragments/fortran_library
These fragments make use of the fcomp macro, which holds the fortran77 compiler command (through the for macro).
We therefore simply replace these macros by new macros named f90comp and f90, defined as follows:
Some languages (this has been seen for example in the IDL generators in Corba environments) do provide several object files from one unique source file. It is possible to specify this feature through the (repetitive) -extra_output_suffix option like in:
This is a generic concept supporting the notion of valued symbols. Several alternate semantics are implemented by these symbols, all specified using the same syntactic schema, but leading to different behaviours or interpretations by CMT:
Variants of these keywords are also provided for modifying already defined symbols. This generally happens when a package needs to modify (append, prepend or subtract) an inherited symbol (ie. which has been already defined by a used package).
The translations occur while running either the setup scripts (for alias, set or path) or the make command (for macro and actions).
All these definitions follow the same pattern:
Be aware that there is only one name space for all kinds of symbols. Therefore, if a symbol was originally defined using a macro statement, using set_append to modify it will produce an undefined result (and a warning message).
The tag expression is used to select one alternate value to replace the default value, using the following matching rule:
Examples of such definition are :
An example of a symple action:
Like other symbols, actions can be visualized using the cmt show actions or the cmt show action <name> command.
Some specialized mechanims are available on actions, in order to execute in various ways the corresponding shell commands.
Actually two operating modes are supported:
This can be done via the cmt do command:
or, when the action name conflicts with a native CMT keyword,
This mode immediately executes the specified command, after locally setting all environment variables known from the current package.
Example 1
Example 2
Describe the relationships with other packages; the generic syntax is :
Omitting the version specification means that the most recent version (ie. the one with highest ids) that can be found from the search path list will be automatically selected.
The offset specification can be relative (i.e. on Unix it does not contain a leading '/' character). In this case, this offset is systematically considered when the package is looked for in the search path list. But it can also be absolute (ie. with a leading '/' character on Unix), in which case this path takes precedence over the standard search path list (see CMTPATH).
The additional -no_auto_imports options suppress the automatic inheritance of some standard parameters from the specified used packages, such as include paths, compiler flags, ...
Examples of such relationships are :
By default, a set of standard macros, which are expected to be specified by used packages, is automatically imported from them (see the detailed list of these macros). This automatic feature can be discarded using the -no_auto_imports option to the use statement, or re-activated using the -auto_imports. When it is discarded, the macros will not be transparently inherited, but rather, each individual constituent willing to make use of them will have to explicitly import them using the -import=<package> option.
When a use statement is in a private section, the corresponding used package will only be reached if when CMT operations occur in the context of the holder package. Otherwise (ie if the operation occurs in some upper level client package), then this privately used package will be entirely hidden. (This behaviour follows a very similar pattern to the private or public inheritance of C++). Suppose we have the following organization:
Often, similar configuration items are needed over a set of packages (sometimes over all packages of a project). This reflects either similarities between packages or generic conventions established by a project or a team.
Typical examples are the definition of the search path for shared libraries (through the LD_LIBRARY_PATH environment variable), the systematic production of test applications, etc.
The concept of pattern proposed here implements this genericity. Patterns may be either global, in which case they will be systematically applied onto every package, or local (the default) in which case they will be applied on demand only by each package.
The general principle of a pattern is to associate a templated (set of) cmt statement(s) with the pattern name. Then every time the pattern is applied, its associated statements are applied as if they were directly specified in the requirements file, replacing the template with its current value. If several statements are to be associated with a given pattern, they will be separated with the " ; " separator pattern (beware of really enclosing the ; character between two space characters).
The general syntax for defining a pattern in a requirements file is:
Pattern templates are names enclosed between the < and > characters. A set of predefined templates are automatically provided by CMT:
package | the name of the current package |
PACKAGE | the name of the current package in upper case |
version | the version tag of the current package |
path | the access path of the current package |
project | the project name of the current package |
Then, in addition, user defined templates can be installed within the pattern definitions. Their actual value will be provided as arguments to the apply_pattern statement.
User defined templates that have not been assigned a value when the pattern is applied are simply ignored (ie. replaced with an empty string).
Some examples:
Changing the standard include search path.
The standard include path is set by default to ${<package>_root}/src. However, often projects need to override this default convention, and typical example is to set it to a branch named with the package name. This convention is easily applied by defining a pattern which will apply the include_path statement as follows:
For instance, a package named PackA will expand this pattern as follows:
Providing a value to the LD_LIBRARY_PATH environment variable
On some operating systems (eg. Linux), shared library paths must be explicited, through an environment variable. The following pattern can automate this operation:
In this example, the pattern was not set global, so that only packages actually providing shared libraries would be concerned. These packages will simply have to apply the pattern as follows:
The schema installed by this pattern provides first a cleanup of the LD_LIBRARY_PATH environment variable and then the new assignment. This choice is useful in this case to avoid conflicting definitions from two different versions of the same package.
Installing a systematic test application in all packages
Quality assurance requirements might specify that every package should provide a test program. One way to enforce this is to build a global pattern declaring this application. Then every make command would naturally ensure its actual presence.
In this example, an additional pattern (<other_sources>) permits the package to specify extra source files to the test application (the pattern assumes at least one source file <package>test.cxx).
Such patterns must be applied explicitly using the apply_pattern construct
Doing so, it is possible to specify custmization values for user defined template parameters
In the apply_pattern syntax, it is even possible to simply ommit the keyword itself, and thus using the pattern name as a plain CMT keyword. The previous example becomes:
This can be seen as a way to extend the CMT language. Notice that there is a risk of a conflict between the primary CMT keywords and pattern names then. Suppose that a pattern name is defined to be exactly a primary CMT keyword. In this case, the syntax parser will always understand this name as the CMT primary keyword, and thus won't override the original syntax. When this (not recommended) situation occurs, it is therefore required to use the full notation with an explicit apply_pattern keyword, so as to avoid any possible ambiguity.
In this case, the pattern is automatically applied to all packages that effectively see the pattern definition, which includes all clients of the package defining the pattern.
Another consequence of the automatic application of the pattern, is that it is not possible to give values to parameters. Therefore it is not recommended to design global patterns with user defined parameters.
Conversely it is possible to inhibit the automatic application of a global pattern in a particular package by using the following statement:
These patterns act quite similarly to the global patterns previously described, ie they defines a set of CMT statements to be applied in a generic way. The difference is that instead of being applied to packages, they are automatically applied to all entries in the CMTPATH list.
Only few system parameters can be used here:
As an example suppose we define
this will assemble one -I option (towards the preprocessor) per entry in CMTPATH, implementing a mechanism for a multiple installation area for header files. In the example above the resulting macro will be
This can be combined with the standard and
automatic macros
(automatically setup for all used packages)
Describe the specific directory branches to be added while configuring the package.
These branches will be created (if needed) at the same level as the cmt branch. Typical examples of such required branches may be include, test or data.
Users can control the behaviour of CMT through a set of strategy specifications. The current implementation provides such control over several aspects :
The build strategy
This controls some aspects of the building process.
The following keywords are available:
prototypes | C source files will automatically produce a header file containing a prototype of all global entry points |
no_prototypes | No production of automatic prototype header files for C sources |
with_installarea | The installation area mechanisms are activated. This implies applying the cmtpath_patterns that may be defined (eg in CMT itself) |
without_installarea | The installation area mechanisms are inhibited |
The setup strategy
This controls various actions that may be performed during the sourcing of the setup scripts.
The following keywords are available:
config | An environment variable <PACKAGE>CONFIG will be generated for all packages in the dependency chain |
no_config | The <PACKAGE>CONFIG environment variable is not generated |
root | An environment variable <PACKAGE>ROOT will be generated for all packages in the dependency chain |
no_root | The <PACKAGE>ROOT environment variable is not generated |
cleanup | The automatic cleanup operation to the current installation area is launched |
no_cleanup | The automatic cleanup operation to the current installation area is not launched |
The strategy specifications are setup on a per-project basis. This means that they are generally applicable to all packages of a given sub-project, and can be oerridden in other sub-projecs of the same software base.
Every strategy setting defines two mutually exclusive tags and activates one of them.
Specify user defined configuration scripts, which will be activated together with the execution of the main setup and cleanup scripts.
The script names may be specified without any access path specification, in this case, they are looked for in the cmt or mgr branch of the package itself. They may also be specified without any .csh or .sh suffix, the appropriate suffix will be appended accordingly when needed. Therefore, when such a user configuration script is specified, CMT expects that the corresponding shell scripts actually exist in the appropriate directory (the cmt branch by default) and is provided in whatever format is appropriate (thus suffixed by .csh and/or .sh).
Override the specification for the default include search
path, which is internally set to
${<package>_root}/src.
Specifying the value none (a reserved CMT keyword) means that no default include search path is expected from CMT, and thus no -I compiler option will be generated by default (generally this means that user include search paths should be specified via explicit include_dirs instead).
Note that this behaviour is expected to become obsolete in some next release of CMT. The default include search path of ../src will then simply disappear, and the include_path statement will become meaningless. When this happens, include search paths will always have to be explicitly specified using the include_dirs statement. In order to anticipate this evolution, it is suggested to always use include_path none and add all include search directories using the include_dirs statement.
Add explicit specifications for include access paths. The value may be provided through a macro reference.
The statement is sensitive to private scoping.
This statement specifies a specialized makefile fragment, used as a building brick to construct the final makefile fragment dedicated to build the constituents.
There are basically three categories of such fragments :
The fragments defined in CMT can be:
Language fragments should provide two forms, one for the applications (in which case they are named exactly after the language name eg c, cpp, fortran) and the other for the libraries (in which case they have the _library suffix (eg. c_library, cpp_library, fortran_library). A set of language definitions (C, C++, Fortran, Java, Lex, Yacc) is provided by CMT itself but it is expected that projects add new languages according to their needs. Event if the make fragment meant to be the implementation of a language support is declared, the language support itself must be declared too, using the language statement
All make fragments are provided as (suffixless) files which must be located in the fragments sub-directory inside the cmt/mgr branch of one package. They must also be declared in the requirements file (through the make_fragment statement) so as to be visible.
A package declaring, and implementing a make fragment may override a fragment of the same name when it is already declared by a used package. This implies in particular that any package may freely override any make fragment provided by CMT itself (although in this case a deep understanding of what the original fragment does is recommended).
Makefile fragments may take any form convenient to the document style, and some special pre-built templates (see the appendix) can be used in their body to represent running values, meant to be properly expanded at actual generation time :
CONSTITUENT | the constituent name |
FULLNAME | the full source path |
FILENAME | the source file name without its path |
NAME | the source file name without its path and suffix |
FILESUFFIX | the dotted file suffix |
FILEPATH | the output path |
SUFFIX | the default suffix for output files |
The public or private keywords introduce sections containing public or private statements. This concerns:
Public definitions are meant to be exported to any client of the package whereas private ones are only available for the package developper ie. when the current directory is within the package itself.
Public use relationships expose the complete sub-tree to the package clients, whereas private ones entirely hide the sub-tree, expanding it only when the operator really acts from within the context of the package. It should be noticed that private use relationships are completely unvisible from clients, which implies that none of the definitions (not only symbols) will be set.
However, the cmt broadcast and cmt show uses commands are configured to always ignore the private specification and therefore will always traverse the sub-trees whether they are public or private (in order to ensure the hierarchy dependencies)
By default cmt commands operate according to the scoping specifications found in the requirements files of the reachable packages. Ie. in the current package all statements are considered whether being prublic or private, while in used packages, only public statements are considered.
This standard behaviour though is not applied when running cmt broadcast or cmt show uses, and in this case all statements public or private, are always considered, even in used packages.
However it is always possible to override the default behaviours by using the -private or -public modifier to the cmt command:
Force the command to consider all definitions even those installed in private sections
Force the command to really mask the private sections
The tag keyword provides tag definitions, while the apply_tag keyword activates a tag.
A tag is a token which can be used to select particular values of symbols.
Some tags are automatically constructed by CMT according to its knowledge of the context (see this section for more details), but they may be also defined within a requirements file as follows :
Running the setup script (through the source setup.[c]sh or call setup.bat command ) can also receive tag specifications using the -tag=tag-list options.
The following sections present the detail of each available command.
These options of the general form -<option> or -<option>=<value> should be provided before the command itself. They give special hints to cmt onto how to perform the command.
Some options have meaning over all commands (such as the -quiet option) while some others only have a meaning in the context of some specialized commands (such as the -with_version_directory option which is only useful for the create or co commands)
The following table describes the various global options of the cmt tool:
-quiet | don't print errors | all | |||
-use=<p>:<v>:<path> | set current package version and path in one option | all | |||
-pack=<package> | set current package, version and root path | all | |||
-version=<version> | |||||
-path=<path> | |||||
-f=<requirement-file> | override input file | all | |||
-e=<statement> | add a one line statement | all | |||
-tag=<tag-list> | select a new tag-set | all | |||
-tag_add=<tag-list> | add specific comma-separated tag(s) | all | |||
-tag_remove=<tag-list> | remove specific comma-separated tag(s) | all | |||
-warnings | displays various warnings, such as invalid PATH items |
|
|||
-with_version_directory | reset to default structuring style |
|
|||
-without_version_directory | switch structuring style |
|
Typical uses of this broadcast operation could be:
The loop over used packages will stop at the first error occurence in the application of the command, except if the command was preceded by a '-' (minus) sign (similarly to the make convention).
It is possible to specify a list of selection or exclusion criteria set onto the package path, using the following options, right after the broadcast keyword. These selection criteria may be combined (eg one may combine the begin and select modifiers)
According to the option, the loop will only operate onto:
The environment variables as specified in the requirements files of the use graph are internally pre-set before running the specified shell command. Thus it's not required to source the setup scripts before using the broadcast command
A priori any Unix or DOS shell command can be specified in a boadcast command. However, it's important to understand the order of the various parsing actions:
Considering this complex sequence of parsing, it may be appropriate to selectively enclose the shell command passed to the broadcast action into quotes. It may even be sometimes useful to have two levels of quotes
Similarly to what exists in the pattern mechanism, some standard templated values can be embedded inside the command to be executed by the broadcast action. They take a standard form of <template-name>. These templates acquire their value on each package effectively reached during the broadcast scan, and the effective value is substituted before launching the command. The possible templates are:
<package_cmtpath> | The element in the CMTPATH search list where the package has been found |
<package_offset> | The directory offset to cmtpath |
<package> | The package name |
<version> | The version of the package |
The next example shows a typical broadcast command listing the header files as expected in the conventional location ../<package> :
The actions associated with the build options are generally meant for internal use only, and users will rarely (if ever!) apply them manually
All build commands are generally meant to change the current package (some file or set of files is generated). Therefore a check against conflicting locks (ie. a lock owned by another user) is performed by all these commands prior to execute it.
This command is internally used by CMT in the standard Makefile.header fragment. It generates a specific makefile fragment (named <constituent-name>.make) which is used to re-build this fragment.
All such constituent fragments are automatically included from the main Makefile.
Although this command is meant to be used internally (and transparently) by CMT when the make command is run, a developer may find useful in very rare cases to manually re-generate the constituent fragment, using this command.
The -nmake option (which must precede the command) provides exactly the same features but in a Windows/nmake context. In this case, all generated makefiles are suffixed by .nmake instead of .make for Unix environments. The main makefile is expected to be named NMake and the standard header is named NMakefile.header
This command is internally (and transparently) used by CMT in the standard Makefile.header fragment, and when the make command is run, to generate a specialized make fragment containing all "cmt build constituent_makefile" commands for a given package.
The -nmake option (which must precede the command) provides exactly the same feature but in a Windows/nmake context. In this case, all generated makefiles are suffixed by .nmake instead of .make for Unix environments. The main makefile is expected to be named NMake and the standard header is named NMakefile.header
This command is internally (and transparently) used by CMT from the constituent specific fragment, and when the make command is run, to generate a fragment containing the dependencies required by a source file.
This fragment contains a set of macro definitions (one per constituent source file), each containing the set of found dependencies.
CMT is able to recursively compute the dependencies implied by the include statements found in the source files. However it's also possible to make plain use of the standard mechanisms provided by some standard tools like cpp -M. In this case, it will be required to format the output produced by the selected tool so as to let CMT parse it and properly deduce the dependencies. Formatting the output of external tools may require to interface the tool itself e.g. using a shell script.
The standard CMT macro $(build_dependencies) must be used to specify an alternate dependency builder. The default value is:
The expected output format from any dependency builder is as follows:
Where:
A Unix shell script in ${CMTROOT}/mgr/cmt_build_deps.sh is offered as an example of how to interface the standard cpp -M command with CMT. It can be declared as a substitute to the internal mechanism as follows:
Of course this shell script should be considered as an example and might have to be adapted for other dependency builders, or for Windows.
This command builds a local symbolic link towards all exported libraries from the used packages. A package exports its libraries through the <package>_libraries macro which should contain the list of constituent names corresponding to libraries that must be exported.
This command generates workspace (.dsw) and project (.dsp) files required for the MSDev tool.
This command generates workspace and project files required for the Visual.net tool.
This command generates external dedicated makefile fragments for each individual component of the package (ie. libraries or executable applications) to be used in OS9 context. It generates specific syntaxes for the OS9 operating systems.
The output of this tool is a set of files (named with the components' name and suffixed by .os9make) that are meant to be included within the main Makefile that the developer has to write anyhow.
The syntax of the cmt build os9_makefile utility is as follows :
This command is internally (and transparently) used by CMT from the constituent specific fragment, and when the make command is run, to generate prototype header files from C source files.
The prototype header files (named <file-name>.ph) will contain prototype definitions for every global entry point defined in the corresponding C source file.
The effective activation of this feature is controled by the build strategy of CMT. The build strategy may be freely and globally overridden from any &CMTrequirements; file, using the build_strategy cmt statement, providing either the "prototypes" or the "no_prototypes" values.
In addition, any constituent may locally override this strategy using the "-prototypes" or "-no_prototypes" modifiers.
This command generates a README.html file into the cmt branch of the referenced package. This html file will include
This command produces onto the standard output, the exhaustive list of all macros controled by CMT, ie. those defined in the requirements files as well as the standard macros internally built by CMT, taking into account all used packages.
An empty output means that everything is fine.
If substitution is performed, a copy (with additional extension sav) is produced.
This command is internally used in the cleanup.[c]sh shell script, itself generated by the cmt config command.
This command (re-)generates the setup scripts and the manimal Makefile (when it does not exist yet or have been lost).
To be properly operated, one must already be in the cmt or mgr branch of a package (where the &CMTrequirements; file can be found).
This command also performs some cleanup operations (eg. removing all makefile fragments previously generated). Generally speaking, one may say that this command restores the CMT-related files to their original state (ie before any document generation)
The situations in which it is useful to run this command are:
It should be noted however that when using actions, such as the one defined by default to launch make tools neither cmt config nor source setup are required any longer.
This command creates a new package or a new version of a package
In the first mode (ie. without the area argument) the package will be created in the default path.
The second mode explicitly provides an alternate path.
A minimal configuration is installed for this new package:
A version directory may be created according to the structuring style or structuring strategy parameters specified using one of the following means:
It should be noted that the command line option will take precedence over the strategy specification, in case of conflict.
The expansion consists in:
cmts: | Perform a unique substitution over one copy of the file |
cmtv: | Perform a multiple substitution over N copies of the file, taking the N space-separated values specified for the parameters |
We consider A containing:
And B containing:
This mechanism is widely internally used by CMT, especially for instanciating make fragments. Then, users may use it for any kind of document, including maual generation of MSDev configuration files, etc...
The arguments needed to reach the package version to be removed are the same as the ones whic had been used to create it.
If the removed version is the last version of this package, (and only if its directory is really empty) the package directory itself will be deleted.
In particular all environment variables defined in requirements file are first set before running the command. This may be seen as a generic application launcher.
This may be combined with the global options -pack=package, -version=version, -path=access-path, to give a direct access to any package context.
This command has no effect when run in the context of a package structured with the version directory
This command must be run while being in the context of one CMT package.
Packages reached during the broadcast scan acquire their version from the original use statement. This is this specified version which will be stored inside the version.cmt files
This command is internally used in the setup.[c]sh or setup.bat shell script, itself generated by the cmt config command.
This command displays all currently defined tags, even when not currenty active
This command displays all patterns actually applied in the current package
This command displays all packages that express an explicit use statement onto the specified package. If no version is specified on the argument list, then all uses of that package are displayed.
Note that the search on clients is not performed recusively. Thus only clients explicitly using the specified package will be displayed.
This command displays all cycles in the use graph of the current package. Although CMT smoothly accepts such cycles, it is generally a bad practice to have cycles in a use graph, because CMT can never decide on the prefered entry point in the cycle, leading to somewhat unpredictable results, eg in constructing the use_linkopts macro.
This command displays the actual location where the specified make fragment is currently found by CMT, taking into account possible overridden definitions.
Display the effective location of all declared make fragments
This command displays all groups possibly defined in constituents of the current package (using the -group=<group-name> option).
Display al languages declared using the language keyword
This set of commands displays a quite detailed explanation on the value assigned to the symbol (macro, set or action) specified as the additional argument. It presents in particular each intermediate assignments made to this symbol by the hierarchy of used statements, as well as the final result of these assignment operations.
By adding a -tag=<tag> option to this command, it is possible to simulate the behaviour of this command in another context, without actually going to a machine or an operating system where this configuration is defined.
This set of commands displays the raw value assigned to the symbol (macro, set or action) specified as the additional argument. It only presents the final result of the assignment operations performed by used packages.
By adding a -tag=<tag> option to this command, it is possible to simulate the behaviour of this command in another context, without actually going to a machine or an operating system where this configuration is defined.
The typical usage of the show macro_value command is to get at the shell level (rather than within a Makefile) the value of a macro definition, providing means of accessing them (quite similarly to an environment variable) :
This set of commands extracts from the &CMTrequirements; file(s) the complete set of symbol (macro, set or action) definitions, selects the appropriate tag definition (or uses the one provided in the -tag=<tag> option) and displays the effective symbol values corresponding to this tag.
This command is typically used to show the effective list of macros used when running make and can be also used to build, as an argument list, the make command as follows :
This use of cmt show macros is directly installed within the default target provided in the standard Makefile.header file. Therefore if this file is included into the package's Makefile, macro definitions provided in the &CMTrequirements; files (the one of the currently built package as well as the ones of the used packages) will be expanded and provided as arguments to make.
By adding a -tag=<tag> option to this command, it is possible to simulate the behaviour of this command in another context, without atcually going to a machine or an operating system where this configuration is defined.
This command displays all packages (and all versions of them) currently reachable through the current access path definition (which can be displayed using the cmt show path command).
This command displays the complete and effective access path currently defined using any possible alternate way.
This command displays how and where the specified pattern is defined, and which packages do apply it.
This command displays all pattern definitions.
This command displays the current knowledge of sub-project definitions and settings. It shows the project names and their location (ie the corresponding item in CMTPATH
This command displays a filtered version of the standard pwd unix command. The applied filter takes into account the set of aliases installed in the standard configuration file located in ${CMTROOT}/mgr/cmt_mount_filter.
This configuration file contains a set of path aliases (one per line) each proposing a translation for non-portable file paths (imposed by mount constraints on some contexts).
This command combines in one go the output of:
This command displays all currently active tags, and what part of the configuration actually activates them
This command displays the use graph fo the current package. Private sections of used packages are reached and considered. This behavior can be changed to effectively hide the private sections in used packages by using the -public modifier
A typical output produced by this command is:
Use statements as specified in the requirements files are displayed, rather than the result of the effective selection performed by CMT
The -quiet option may be used to remove the first section from the output so as to only display a simple list of used packages, starting from the deepest uses.
This command displays all possible paths between the current package and the specified used target package.
In particular this will detect if a package has no access to another one, due to private use statements
This command displays the version tag of the current package.
This command displays the reachable versions of the specified package, looking at the current access paths.
One flavour of these scripts is generated per shell family (csh, sh and bat), yielding the following scripts :
The main sections installed within a setup script are :
The generated prototype header file is meant to be included whereever it is needed (in the module file itself for instance).
A typical example of the use of cmt build prototype could be :
Running cmt build prototype will only produce a new prototype header file if the output is actually different from the existing one (if it exists) in order to avoid confusing make checks.
The effective use of this facility (which may not be appropriate in all projects) is controlled by one option of the build strategy, which can take one of the two values:
In addition to this global strategy specification, each application or library may individually override it using the -prototypes or -no_prototypes options.
Lastly, the actual behaviour of the prototype generator is defined in the standard make macro build_prototype (which default to call the cmt build prototype command, allowing a user defined behavious to this feature)
Nothing special is apriori required by CMT with respect to the use of CVS. Nevertheless, one may advertize some well tested conventions and practices which turned out to ensure a good level of consistency between the two utilities.
Although none of these are required, the cmt general command provides a few utilities so as to simplify the use of these practices. It should be noted that the added features provided by cmt rely on the possibility to query CVS about the existing CMT packages and the possible tags setup for these packages. CVS does not by default permit such query operations (since they require to scan the physical CVS repository). Therefore CMT provides a hook to CVS (based upon standard CVS features - not patches) for this. This hook can be installed following a recipe explained in the dedicated appendix.
Generally, everything composing a package (below the version directory and besides the binary directories) is relevant to be imported. Then choosing a cvs module name is generally done on the basis of the package name. Taking the previous examples, one could import the Foo package as follows :
In this example,
The choice of the module name can generally be identical to the package name. However, some site specific management issues may lead to different choices (typically, a top directory where groups of packages are gathered may be inserted).
Conversely, using symbolic tags identical to version identifiers appears to be a very good practice. The only constraint induced by cvs is that the symbolic tags may not contain dot characters ('.'), whereas no restriction exist from CMT itself. Thus version identifiers like v3r2 will be preferred to the v3.2 form.
Assuming the previous conventions on module name and version identifier have been selected when importing a package, the following operations will naturally intervene when one need to check a package out (typically to work on it or to install it on some platform) :
The actions decribed just above (from number 2 to number 4 included) can also be performed using the cmt checkout command.
to query the CVS repository about the existing tags installed onto a given CVS module, the subdirectories and the subpackages (in the CMT meaning, i.e. when a requirements file exists).
One should notice here that the cvstags command can give informations about any type of module, even if it is not managed in the CMT environment.
However, in order to let this mechanism operate, it is required to install some elements into the physical CVS repository ( which may require some access rights into it). This installation procedure (to be done only once in the life of the repositiory) can be achieved through the following command:
However, the details of the procedure is listed below (this section is preferably reserved for system managers and can easily be skipped by standard users):
This section presents the way to instanciate a new release of a given package, which happens when the foreseen modifications will yield additions or changes to the application programming interface of the package.
Then the version tag is supposed to be moved forward, either increasing its minor identifier (in case of simple additions) or its major identifier (in case of changes).
The following actions should be undertaken then :
The previous example presented the standard case where one gets the most recent version of a given package. The procedure is only slightly modified when one wants to extract a previously tagged version. Let's imagine that the Foo package has evolved by several iterations, leading to several tagged releases in the cvs repository (say v2 and v3). If the v2 release is to be used (e.g. for understanding and fixing a problem discovered in the running version) one will operate as follows :
Very often, external packages (typically commercial products, or third party software) are to be used by packages developped in the context of the CMT environment. Although this can obviously done simply by specifying compiler or linker options internally to the client packages, it can be quite powerful to interface these so-called external packages to CMT by defining a glue package, where configuration specifications for this external package are detailed.
Using this approach, one may :
Then every package or application, client of this OPACS package would have just to provide a use statement like :
This procedure gives the complete benefit of the use relationships between packages (a client application transparently inherits all configuration specifications) while keeping unchanged the original referenced package, allowing to apply this approach even to commercial products so that they may be integrated in resource usage surveys similarly to local packages.
CMT proposes and implements a flexible architecture for installation areas, meant to group the results of the build process or any other information belonging to packages into shared disk spaces. The typical usage of such installation areas is classical and expect to make only visible to the clients of a given (sub-)project the results of the build process while hiding the details of the package sources.
the basics of the mechanisms supported by CMT are the following:
It is provided in terms of
application | applications |
library | shared libraries |
library_no_share | static libraries |
java_header | Java applications |
jar | Java libraries |
One shell script for installing or uninstalling files or directories
The default architecture of this installation scheme is by default set for each CMTPATH entry to:
The <project>_installarea_prefix takes the default value of $(cmt_installarea_prefix) for all projects, which itself takes the default value of InstallArea. Of course it can be overridden to other values in each project
The cmtpath_patterns are designed in this implementation for constructing a proper and consistent sequence of system specific environment variables (eg PATH, LD_LIBRARY_PATH, CLASSPATH) as well as compiler or linker options so as to transparently refer to the installation area only when it is appropriate to ovverride the local patterns.
First of all every individual sub-project may activate or inhibit the installation area mechanisms using the build_strategy statement, with either with_installarea or without_installarea option.
Then a dedicated tag materializes the selected strategy: <project>_with_installarea or <project>_without_installarea
This tag set will be used in various macro or set definitions to produce or not the appropriate values
CMT manipulate some standard macros or environment variables according to the effective strategy:
cmt_installarea_prefix | The default prefix for all projects | InstallArea |
<project>_installarea_prefix | The prefix for a given sub-project | $(cmt_installarea_prefix) |
<project>_installarea_prefix_remove | The regexp pattern to cleanup symbols | $(<project>_installarea_prefix) |
cmt_installarea_linkopts | Implicit linker options due to the installation area | ... |
PATH | Accessing the executables in the installation area | ... |
LD_LIBRARY_PATH | Accessing the shared libraries in the installation area | ... |
CLASSPATH | Accessing the jar files in the installation area | ... |
These sections are of interest only if CMT is not yet installed on your site, of if you need a private installation.
The first question you need to answer is the location where to install CMT. This location is typically a disk area where most of packages managed in your project will be located.
Then, you have to fetch the distribution kit from the Web at http://www.cmtsite.org. You must get at least the primary distribution kit containing the basic configuration information and the CMT sources. This operation results in a set of directories hanging below the CMT root and the version directory. The src branch contains the sources of CMT, the fragments branch contains the makefile fragments and the mgr branch contains the scripts needed to build or operate CMT.
The very first operation after dowloading CMT consists in running the INSTALL shell script. This will build the setup scripts required by any CMT user.
Then you may either decide to build CMT by yourself or fetch a pre-built binary from the same Web location. The prebuilt binary versions may not exist for the actual platform you are working on. You will see on the distribution page the precise configurations used for building those binaries.
In case you have to build CMT yourself, you need a C++ compiler capable of handling templates (although the support for STL is not required). There is a Makefile provided in the distribution kit which takes g++ by default as the compiler. If you need a specific C++ compiler you will override the cpp macro as follows:
The cppflags macro can also be used to override the behaviour of the compilation.
Another important concern is the way CMT will identify the platform. CMT builds a configuration tag per each type of platform, and uses this tag for naming the directory where all binary files will be stored. As such this tag has to be defined prior to even build CMT itself.
CMT builds the default configuration by running the cmt_system.sh script found in the mgr branch of CMT. Run it manually to see what is the default value provided by this script. You might consider changing its algorithm for your own convenience.
A distribution kit may be obtained at the following URL :
Once the tar file has been downloaded, the following operations must be achieved :
A typical corresponding session could look like :
You first have to fetch the distribution kit from the Web at http://www.cmtsite.org. You must get at least the primary distribution kit containing the basic configuration information and the CMT sources. This operation results in a set of directories hanging below the CMT root and the version directory. The binary kit provided for Windows environments will generally fit your needs.
You should consider getting the pre-compiled (for a Windows environment) applications, and especially the ..\VisualC\install.exe application, which interactively configures the registry entries as described in the next paragraph.
The next operation consists in defining a few registries (typically using the standard RegEdit facility or the install.exe special application):
CMT can also be configured to run on DOS-based environments using the nmake facility. In this case, the installation procedure is very similar to the Unix one:
A typical corresponding session could look like :
This software is a computer program whose purpose is to describe and manage software configuration activities.
This software is governed by the CeCILL license under French law and abiding by the rules of distribution of free software. You can use, modify and/ or redistribute the software under the terms of the CeCILL license as circulated by CEA, CNRS and INRIA at the following URL
As a counterpart to the access to the source code and rights to copy, modify and redistribute granted by the license, users are provided only with a limited warranty and the software's author, the holder of the economic rights, and the successive licensors have only limited liability.
In this respect, the user's attention is drawn to the risks associated with loading, using, modifying and/or developing or reproducing the software by the user in light of its specific status of free software, that may mean that it is complicated to manipulate, and that also therefore means that it is reserved for developers and experienced professionals having in-depth computer knowledge. Users are therefore encouraged to load and test the software's suitability as regards their requirements in conditions enabling the security of their systems and/or data to be ensured and, more generally, to use and operate it in the same conditions as regards security.
The fact that you are presently reading this means that you have had knowledge of the CeCILL license and that you accept its terms.
These targets can always be listed through the following command :
|
|
help | Get the list of possible make target for this package. |
all | build all components of this package. |
clean | remove everything that can be rebuilt by make |
binclean | completely remove the ../$(tag) binary directory |
configclean | remove all intermediate makefile fragments |
install | install binaries of this package to the current installation area |
uninstall | uninstall binaries of this package from the current installation area |
check | run all applications defined with the -check option |
component-name | only build this particular component (as opposed to the all target that tries to build all components of this package) |
group-name | build all constituents belonging to this group (ie. those defined using the same -group=<group-name> option) |
These targets have to be specified as follows :
|
|
|
CMTrelease | gives the current release number of CMT | &CMTrelease; |
CMTVERSION | gives the current complete version tag of CMT | &CMTVersion; |
|
|
|
tag | gives the binary tag | ${CMTCONFIG} |
src | the src branch | ../src/ |
inc | the include branch | ../src/ |
mgr | the cmt or mgr branch | ../cmt/ or ../mgr/ |
bin | the branch for binaries | ../$(<package>_tag)/ |
javabin | the branch for java classes | ../classes/ |
doc | the doc branch | ../doc/ |
cmt_hardware | the description of the current hardware | <none> |
cmt_system_version | the version of the current OS | <none> |
cmt_compiler_version | the version of the currently visible C++ compiler | <none> |
During the mechanism of new language declaration and definition available in the CMT syntax, developers are expected to define similar conventions for corresponding actions.
Their default values are originally defined inside the &CMTrequirements; file of the CMT package itself but can be redefined by providing a new definition in the package's requirements file using the macro statement. The original definition can be completed using the macro_append or macro_prepend statements.
|
|
|
cc | The C compiler | cc |
ccomp | The C compiling command | $(cc) -c -I$(inc) $(includes) $(cflags) |
clink | The C linking command | $(cc) $(clinkflags) |
cflags | The C compilation flags | none |
pp_cflags | The preprocessor flags for C | none |
clinkflags | The C link flags | none |
cpp | The C++ compiler | g++ |
preproc | The C++ preprocessor | g++ -MD -c |
cppcomp | The C++ compiling command | $(cpp) -c -I$(inc) $(includes) $(cppflags) |
cpplink | The C++ linking command | $(cpp) $(cpplinkflags) |
cppflags | The C++ compilation flags | none |
pp_cppflags | The preprocessor flags for C++ | none |
cpplinkflags | The C++ link flags | none |
for | The Fortran compiler | f77 |
fcomp | The Fortran compiling command | $(for) -c -I$(inc) $(includes) $(fflags) |
flink | The Fortran linking command | $(for) $(clinkflags) |
fflags | The Fortran compilation flags | none |
pp_fflags | The preprocessor flags for fortran | none |
flinkflags | The Fortran link flags | none |
ppcmd | The include file command for Fortran | -I |
javacomp | The java compiling command | javac |
jar | The java archiver command | jar |
lex | The Lex command | lex $(lexflags) |
lexflags | The Lex flags | none |
yacc | The Yacc command | yacc $(yaccflags) |
yaccflags | The Yacc flags | none |
ar | The archive command | ar -clr |
ranlib | The ranlib command | ranlib |
They are automatically and by default concatenated by CMT to fill in the corresponding global use macros (see appendix on generated macros). However, this concatenation mechanism is discarded when the -no_auto_imports option is specified in the corresponding use statement.
|
|
<package>_cflags | specific C flags |
<package>_pp_cflags | specific C preprocessor flags |
<package>_cppflags | specific C++ flags |
<package>_pp_cppflags | specific C++ preprocessor flags |
<package>_fflags | specific Fortran flags |
<package>_pp_fflags | specific Fortran preprocessor flags |
<package>_libraries | gives the (space separated) list of library names exported by this package. This list is typically used in the cmt build library_links command. |
<package>_linkopts |
provide the linker options required by any application willing to
access the different libraries offered by the
package. This may include support for several libraries
per package.
A typical example of how to define such a macro could be : |
<package>_stamps |
may contain a list of stamp file names (or make
targets). Whenever a library is modified, one dedicated
stamp file is re-created, simply to mark the
reconstruction date. The name of this stamp file is
conventionally <library>.stamp. Thus,
a typical definition for this macro could be :
Then, these stamp file references are accumulated into the standard macro named use_stamps which is always installed within the dependency list for applications, so that whenever one of the libraries used from the hierarchy of used packages changes, the application will be automatically rebuilt. |
The following macros are not subject to automatic concatenation (and therefore are not hidden by the -no_auto_imports modifier).
|
|
<package>_native_version | specifies the native version of the external package
referenced by this interface package. When this macro is provided, its value is displayed by the cmt show uses command |
<package>_export_paths | specifies the list of files or directories that should be exported during the deployment process for this package. Generally this is only useful for glue packages refering to external software |
<package>_home | specifies the base location for external software described in glue packages. This macro is generally used to specify the previous one |
By convention, they are all prefixed by the constituent name. But macros used for defining compiler options are in addition prefixed by the constituent type (either lib_, app_ or doc_).
They are used in the various make fragments for fine customization of the build command parameters.
<type>_<constituent>_cflags | specific C flags |
<type>_<constituent>_pp_cflags | specific C preprocessor flags |
<type>_<constituent>_cppflags | specific C++ flags |
<type>_<constituent>_pp_cppflags | specific C++ preprocessor flags |
<type>_<constituent>_fflags | specific Fortran flags |
<type>_<constituent>_pp_fflags | specific Fortran preprocessor flags |
<constituent>linkopts | provides additional linker options to the application. It is complementary to - and should not be confused with - the <package>_linkopts macro, which provides exported linker options required by clients packages to use the package libraries. |
<constituent>_shlibflags | provides additional linker options used when building a shared library. Generally, a simple shared library does not need any external reference to be resolved at build time (it is in this case supposed to get its unresolved references from other shared libraries). However, (typically when one builds a dynamic loading capable component) it might be desired to statically link it with other libraries (making them somewhat private). |
<constituent>_dependencies | provides user defined dependency specifications for each constituent. The typical use of this macro is fill it with the name of the list of some other constituents which have to be rebuilt first (since each constituent is associated with a target with the same name). This is especially needed when one want to use the parallel gmake (ie. the -j option of gmake). |
<group>_dependencies | provides user defined dependency specifications for each group. The typical use of this macro is fill it with the name of the list of some other constituents which have to be rebuilt first (since each constituent is associated with a target with the same name). This is especially needed when one want to use the parallel gmake (ie. the -j option of gmake). |
By convention, they are all prefixed by the source file name followed by the source file suffix (either _c, _cxx, _f, etc.)
They are used in the various make fragments for fine customization of the build command parameters.
<constituent>_<suffix>_cflags | specific C flags |
<constituent>_<suffix>_cppflags | specific C++ flags |
<constituent>_<suffix>_fflags | specific Fortran flags |
These macros are automatically generated when any cmt connand is run (and thus when make is run).
The first set of them provide constant values corresponding to CMT based information. They are not meant to be overridden by the user, since they serve as a communication mean between CMT and the user.
<PACKAGE>ROOT | The access path of the package (including the version branch). This is controlled by the setup_strategy [no_]root statement. |
<package>_root | The access path of the package (including the version branch). This macro is very similar to the <PACKAGE>ROOT macro except that it tries to use a relative path instead of an absolute one. |
<PACKAGE>VERSION | The used version of the package. |
PACKAGE_ROOT | The access path of the current package (including the version branch) |
package | The name of the current package |
version | The version tag of the current package |
package_offset | The directory offset of the current package |
package_cmtpath | The package area where the current package has been found |
<package>_project | The project name to which the corresponding package belongs |
<package>_cmtpath | The package area where the corresponding package has been found |
<package>_offset | The directory offset of the corresponding package |
The second set is deduced from the context and from the requirements file of the package. They can be overridden by the user so as to customize the CMT behaviour.
<package>_tag | The specific configuration tag for the package. By default it is set to $(tag) but can be freely overridden |
constituents | The ordered set of constituents declared without any group option |
<group-name>_constituents | The ordered set of all constituents declared using a group=<group-name> option |
The third set of generated macros are the global use
macros. They correspond to the concatenation of the
corresponding package specific customizing options that can be
deduced from the ordered set of use statements found in the
requirements file (taking into account the complete hierarchy of
used packages with the exception of those specified with the
-no_auto_imports option in their use statement) :
use_cflags | C compiler flags |
use_pp_cflags | Preprocessor flags for the C language |
use_cppflags | C++ compiler flags |
use_pp_cppflags | Preprocessor flags for the C++ language |
use_fflags | Fortran compiler flags |
use_pp_fflags | Preprocessor flags for the Fortran language |
use_libraries | List of library names |
use_linkopts | Linker options |
use_stamps | Dependency stamps |
use_requirements | The set of used requirements |
use_includes | The set of include search paths options for the preprocessor from the used packages |
use_fincludes | The set of include search paths options for the fortran preprocessor from the used packages |
includes | The overall set of include search paths for the preprocessor |
fincludes | The overall set of include search paths options for the fortran preprocessor |
cmt_installarea_command
cmt_uninstallarea_command
cmt_install_action
$(CMTROOT)\mgr\cmt_install_action.bat
cmt_installdir_action
$(CMTROOT)\mgr\cmt_installdir_action.bat
cmt_uninstall_action
$(CMTROOT)\mgr\cmt_uninstall_action.bat
cmt_uninstalldir_action
$(CMTROOT)\mgr\cmt_uninstalldir_action.bat
cmt_installdir_excludes
$(CMTROOT)\mgr\cmt_installdir_excludes.txt
cmt_installarea_prefix
InstallArea
<project>_installarea_prefix
$(cmt_installarea_prefix)
CMTINSTALLAREA
C:\Arnault\test\tprojects\PC\InstallArea
cmt_installarea_paths
cmt_installarea_linkopts
X11_cflags | compilation flags for X11 | -I/usr/include |
Xm_cflags | compilation flags for Motif | -I/usr/include |
X_linkopts | Link options for XWindows (and Motif) | |
make_shlib | The command used to generate the shared library from the static one | ${CMTROOT}/mgr/cmt_make_shlib_common.sh extract |
shlibsuffix | The system dependent suffix for shared libraries | so |
shlibbuilder | The loader used to build the shared library | g++ |
shlibflags | The additional options given to the shared library builder | -shared |
application_suffix | The default extension for applications | .exe |
library_prefix | The default name prefix of libraries | lib |
library_suffix | The default name suffix of libraries | |
symlink | The command used to install a symbolic link | /bin/ln -fs |
The command used to remove a symbolic link | /bin/rm -f | |
build_prototype | The command used to generate the C prototype header file (default to the internal cmt dedicated command) | $(cmtexe) build prototype |
build_dependencies | The command used to generate dependencies (default to the internal cmt dedicated command) | $(cmtexe) -quiet -tag=$(tags) build dependencies |
lock_command | The command used to physically lock a package | chmod -R a-w ../* |
unlock_command | The command used to physically unlock a package | chmod -R g+w ../* |
make_hosts | The list of remote host names which exactly require the make command | |
gmake_hosts | The list of remote host names which exactly require the gmake command |
CMTv<n> | Primary version id of CMT | ||
CMTr<n> | Secondary version id of CMT | ||
CMTp<n> | Patch id of CMT | ||
`uname` | The basic platform id | ||
<project-name> | The current project name | ||
|
The prototypes strategy for each project | ||
|
The installation area strategy for each project | ||
|
The strategy for generating <P>CONFIG for each project | ||
|
The strategy for generating <P>ROOT for each project | ||
|
The installation area cleanup strategy for each project |
ADDINCLUDE | additional include path | <language> java |
CONSTITUENT | name of the constituent | <language> java jar make_header jar_header java_header library_header application_header protos_header library_no_share library application dependencies cleanup_header cleanup_library cleanup_application check_application document_header <document> trailer dsw_all_project_dependency dsw_project dsp_library_header dsp_shared_library_header dsp_windows_header dsp_application_header dsp_trailer constituent check_application_header |
DATE | now | make_header |
FILENAME | file name without path | buildproto <language> <document> |
FILEPATH | file path | buildproto <language> <document> |
FILESUFFIX | file suffix (without dot) | <language> |
FILESUFFIX | file suffix (with dot) | <document> |
FULLNAME | complete file path and name | <language> cleanup <document> dsp_contents |
GROUP | group name | constituents_header |
LINE | source files | <language> dependencies constituent |
LINKMACRO | link macro | application |
NAME | file name without path and suffix | buildproto <language> java <document> |
OBJS | object files | jar_header java_header jar library_no_share library application cleanup_java document_header trailer |
OUTPUTNAME | output file name | java |
PACKAGE | current package name | <language> dsw_header dsw_all_project dsw_all_project_trailer dsw_trailer dsp_all readme_header readme readme_use readme_trailer |
PACKAGEPATH | current package location | readme_use |
PROTOSTAMPS | prototype stamp files | protos_header |
PROTOTARGET | prototype target name | library_header application_header |
SUFFIX | document suffix | <document> |
TITLE | title for make header | make_header |
USER | user name | make_header |
VERSION | current package version tag | readme_header readme readme_use |
constituents.make | the main entry point point for all constituent targets |
|
<constituent>.make | application or library specific make fragment |
|
<constituent>.make | document specific make fragment |
|
<package>.dsw | Visual workspace configuration files |
|
<constituent>.dsp | Visual project configuration files |
|
README | . |
|
CMT provides a hook that can be installed within a CVS repository, based on a helper script that will be activated upon a particular CVS command, and that is able to perform some level of scan within this repository and return filtered information.
More precisely, this helper script (found in ${CMTROOT}/mgr/cmt_buildcvsinfos2.sh) is meant to be declared within the loginfo management file (see the CVS manual for more details) as one entry named .cmtcvsinfos, able to launch the helper script. This installation can be operated at once using the following sequence:
This mechanism is thus fully compatible with standard remote access to the repository.
Once the helper script is installed, the mechanism operates as follows (this actually describes the algorithms installed in the CvsImplementation::show_cvs_infos method available in cmt_cvs.cxx and is transparently run when one uses the cmt cvsxxx commands):
Obviously this command is fake, since no file exist in the temporary directory we have just created. The protocol-level referenced in this command is described in the standard macro $(cmt_cvs_protocol_level).