AMMA FAQ
|
AMMA QUESTIONS
|
|
|
This page covers frequently asked questions (FAQ) about AMMA.
|
This page addresses a range of issues concerning AMMA. For example compiler
issues multiple template symbol definitions, and other such compiler problems.
Also the more common RCS problems are explained.
There can be several reasons. The amma library is updated every night.
Changes during a day are not propagated immediately. If you need to update
the amma and/or gama system immediately (in a case of emergency), you must
ask the
CVSSP
Software Manager.
If amma making system detects any suspicious messages during updating,
it does not change the public area. If expected changes were not
propagated into the public area, the log files of making can be checked
in the directory /vol/vssp/local/develop/amma/log or on the 'Update'
web page.
One can use different packages, for example leda, wxWindows, xor++, etc.
The following syntax should be used for including of files:
#include <leda/sllist.h>
#include <leda/vector.h>
#include <xor/base.h>
#include "amma/DList.hh"
#include "amma/vector.h"
Otherwise it can be hard to recognize to which packages an included header
file belongs.
Futhermore this syntax avoids the include file names clashing (for example
the include file name vector.h in the above example). It is compulsory to use
this syntax in amma library (not for gama). The second amma in the path
is just the first part of the file name in the include directive.
Same goes for the gama inc.
Not using the correct version of RCS
To use the AMMA system, the version of ci/co that reside in
/vol/vssp/local/tools/bin must be used.
This can be checked by typing where ci
Incorrect RCS directory link.
If the soft link to the RCS directory not created correctly (the link
points to a non-existent directory etc.), ci/co will fail. To check
whether the RCS link is OK, do cd RCS; cd .. . Now your
current directory should be in the amma/gamm system.
File with the ',' prefix exists in RCS
In a number of situations, the RCS system creates a file with ',' prefix
if an operation fails. Such file usually prevents ci/co from succefull
completion. Move this file out of the RCS directory (do not remove it,
it might contain the only correct copy of your file!) and repeat ci/co.
User not on the access list
The problem occurs when you are trying to correct or append code you have
not written yourself. If you are not on the access list, you will be able
to issue co file but not co -l file . Check
the access list by rlog file .
File/Directory not readable by eevsspsoft
For the AMMA system ci to work correctly, directories and files
maintained under AMMA/GAMA must be readable by the evvsspcpug group.
So, a directory with an RCS directory that is a link to the AMMA/GAMA space
must have +x permission for group if it is owned by eevsspcpug group
(check by ls -lg) or +x for 'other' otherwise.
Not member of the eevsspcpug group
All contributors to the amma system must be members of the eevsspcpug group.
Check this by typing groups . See the AMMA home for information
about registering as a user.
Incorrect RCS permissions
The RCS directory under amma/gama should have the follwoing permission setting:
drwxrwsr-t . If this is not the case, contact the administrator
of the amma/gama system.
What is the cause of "co error: writable name.cc
exists; checkout aborted"?
The file name.cc was checked in using the command "ci -l name.cc".
Unfortunately, in this case ci does not update the date of
the file name.cc to be
younger than the file RCS/name.cc,v. The solution is to check in and
check out separately.
It can occur that during linking of executable or during trial linking
of libraries multiple defined symbols appear. They should be always
only the symbols generated by template classes or template functions.
On SGI architecture the problem is autmaticly solved. On Solaris 2
you received the warning which contains the object modules which clash.
On Alpha .....
At least one of them must be deleted including the corresponding file
*.rpo containing information how templated should be generetated.
From the design point of view libraries create a tree (or generally a forest).
In amma system we use the repository scheme which enables fast compilation and
minimum space requirement. Unfortunately it forces us to create a chain (linear
structure) from all libraries. Therefore it must be always decided which
library generates template symbols and which will only use them. The order of
the building of libraries is defined by the variable NESTED. The variable OPTLIB
must contain the libraries in the reverse order. For example, let us have
two libraries aa and bb which are not related from the design point of view, but
they use the same template function, and they are located in directories Daa
and Dbb, respectively. We can set that the library bb should be compile before
aa, eg. NESTED = Dbb.r Daa.r. Furthermore, in the defs.mk file of aa library we
must define OPTLIB = -laa -lbb, and in the directory Dbb the defs.mk
file will contain OPTLIB = -lbb only.
It happens. There are 2 cases. We detected the first on alpha machine
when combining GAMA and AMMA libraries. The cause is unknown.
The second case has happened on SGI machine when one library has got
different ownership than others.
We are still collecting more evidence to trace the problem.
It is not a rare case that two libraries on two different branches of the
tree (forest) of libraries need to generate the same template class.
Under the repository scheme one of these libraries must be made dependent
on the second one. If it is not easy to find the right order of the libraries
or it is not meaningful, it is possible to generate a required template
at the joint of both branches with the libraries. Generally the best
place is the first library in the order of libraries which can generate
such template.
How to generate a such template class? It is quite easy. It is just enough
to create the line with the forward declaration of the template class
as follows:
template class Array1dC;
This line after including of proper header files causes a generation of
the class Array1dC. To generate all symbols of the class
including inhereted ones, one must list all base template classes.
In the future the mechanismus of generation of template classes can
be based on a different paradigm. Therefore, in AMMA system we use
the suffix '.cxx' to distinguish files for generation of templates classes.