RADE

Unix Workspace's images

They must be created by specifying a full path name for the root directory. On Unix, this path name must start with '/u/users' or '/u/lego' if the image is intended to be used from various machine over the local network. Conversely there is no rule enforced on the path name if it is local to the machine where the command (adl_mk_ws, adl_mk_image, adl_set_image) is run; use the -local_dir option to specify that one image's path name is local to the current host.

Unix restriction: the character '\' is forbidden in Unix image paths

File Tree

Like the other CAA V5 development tools, SCM follows some rules regarding the files and directories that can be found under the workspace root directory (images for SCM). The figures here after show the file tree structure from the root directory to the deepest levels.

	The directories that can be found right under the file tree root directory correspond to frameworks. Three kind of frameworks can be created (adl_mk_fw): code framework (no suffix) test framework (.tst suffix) education framework (.edu suffix) Framework cannot be nested and must be created right under the root directory. Note: some other directories may appear while working using CAA V5 tools because some useful stuffs are stored by tools in each file tree (intel_a, ToolData, ..., directories).
	There are three kinds of directories that can be found under a framework root directory: the "IdentityCard" directory contains the description file of the framework (prerequisite frameworks, ...) the "PublicInterfaces", "ProtectedInterfaces" and "PrivateInterfaces" directories contain header files other directories correspond to code or data modules. SCM forbids users for declaring directories that are not listed above.
	Modules are always created right under the root directory of the embedding framework: code modules have predefined suffixes data modules can have any suffix except those defined for code modules. The only directories a code module can contain are: a "LocalInterfaces" directory for gathering local header files a "src" directory containing source files The internal structure of a data module is free.

[Top]

Component Naming

Framework

Framework names may be with or without suffix but allowed suffixes are "edu" and "tst" only. The "edu" suffix is used for education frameworks (documentation) while the "tst" suffix is used for test frameworks. A code framework name has no suffix.

It is advised to use the same name for code, education and test framework and let the suffix makes the difference:

• XXX being a code framework
• XXX.tst will be the associated test framework
• XXX.edu will be the associated documentation framework

A framework name must be at least 1 character long and at most 30 character long.

The name "ToolsData" is reserved for SCM.

[Top]

Module

There are two kinds of modules: data and code modules.

A code module

• is used to deliver source files, external libraries or documentation
• is uniq in a workspace tree
• is a "buildable" module, that is to say should contain a Imakefile.mk file (it is not checked)

A data module

• is used to deliver CAA V5 resource files (message files, icons, etc)
• is used to deliver any particular stuffs not necessarily recognized by RADE tools
• is not uniq in a workspace tree
• is not a "buildable" module, that is to say it does not contain a Imakefile.mk file

Suffixes that are allowed for a code module are

• "m" for C, C++ source files
• "mext" for external libraries
• "mj" for java source files
• "mjext" for external java libraries (jar)
• "doc" for documentation module

All suffixes are allowed for data modules except those dedicated to code modules.

SCM does not check anything on the data module name but consult the build tool documentation because some names are meaningfull:

• "CNext" contains runtime data for all operating systems
• "CNext.specifics_UNIX" contains runtime data specific to the UNIX platform
• etc

A module name must be at least 3 character long and at most 128 character long.

[Top]

Element (File/Directory)

All the characters are allowed except those listed below

* ? \ / < > " ' | :

A header file ("h" suffix) cannot be created twice in a workspace tree by default. However it is possible to force a creation in such a case. The only header file that can be created more than once is the IdentityCard.h file. Here is an example of the message displayed by SCM when one user tries to create a file that already exists in the database:

E:\devt\>adl_mk_elem XFiles.h
objects whose names conflict with "XFiles.h" in the workspace devt hierarchy in the workspace tree ProductV1_1:
   "fw1\mod1.m\LocalInterfaces\XFiles.h" (File element) in the workspace Int_Application1 in the workspace tree ProductV1_1
Looking for an existing header named "XFiles.h"
# ADLCMD - 1139: An existing object "fw1\mod1.m\LocalInterfaces\XFiles.h" (File element) (a header into any folder or an object into the same folder) has been found in the workspace hierarchy.
Choose another name, or use -force option

On Windows-NT platform, full paths must not exceed 260 characters. However, as any SCM operation on a user file system is performed under transaction control, any new file or directory appears temporarily with a two character suffix. By the way, it is advised to use full paths containing at most 200 characters.

Due to Windows-NT management of files, comparisons on file and directory names are not case significant (even on UNIX platform). For instance the "a.cpp" file is the same as the "A.CPP" file or the "A.cpp" file.

[Top]

File Suffixes

Any file with any suffix can be managed in a workspace, however its suffix must be recognized by SCM when creating it the first time. The adl_ls_type command gives the list of predefined suffixes and four basic types [1] can be used according to the file behaviour.

[Top]

Object names

The characters allowed in a workspace name, image name or a tree name are:

• [a-z]
• [A-Z]
• _ (underscore)

Other characters are not allowed (for instance like national accented characters).

[Top]

File Contents

The only checking made on file contents is to check if the last character is a "end of line". This control has been set up because some tools (like compilers) may fail in such a case. As workspaces are used for exchanging files, a given file may compile in a workspace (on a given platform) and causes the compilation to fail in another workspace (on another platform). That is why SCM forbids such files to be registered within a workspace.

[Top]

References

History

Copyright © 2000, Dassault Systèmes. All rights reserved.