gov.llnl.babel.backend
Class Dependencies
java.lang.Object
gov.llnl.babel.backend.Dependencies
- All Implemented Interfaces:
- FileListener
public class Dependencies
- extends java.lang.Object
- implements FileListener
Make depends info calculator for all languages.
We have a nested map structure:
d_dirMap contains elements indexed by dirname
and with hashmaps as values. The hashmap values
are themselves hashmaps keyed by filename with
a value the vector of filenames of prerequisites.
Note on terminology: this is about makefile dependency rules of the form
output : input
where input and output may be lists and may be path qualified or not.
It turns out that without a more restrictive definition of the C/C++/fortran
code generation, we cannot determine the directory in which the included
headers will exist because, for example, the IOR headers may be kept
canonically elsewhere and generated by an alternate invocation of babel.
Similarly, headers from other sidl packages not included in the same
generation step be be anywhere in the filesystem. Thus, the best dependency
we can generate is by filenames only on the rhs of the : in a make rule and
the rest of the work must be provided by VPATH in gnu make or equivalent.
On the whole, the difficulties stem from a deep inconsistency in how various
languages are handled. E.g. xml files can always determine the full path to
other xml files at babel invocation time. In python and java there is some
package structure, but not enough to guarantee anything. In C, etc, the
user can pretty much do anything they want.
Methods inherited from class java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
Dependencies
public Dependencies(Context context)
setOutputDir
public void setOutputDir(java.lang.String outdir)
addTargetFile
public void addTargetFile(java.lang.String dirName,
java.lang.String fileName)
addInput
public void addInput(java.lang.String input)
getDirectoryData
public java.util.HashMap getDirectoryData(java.lang.String dirName)
dumpData
public void dumpData()
recordDependency
public void recordDependency(SymbolID id)
- Method for recording makefile dependencies. Do not
use unless you know exactly what you are doing.
recordDependency
public void recordDependency(Symbol symbol)
newFile
public void newFile(SymbolID id,
int type,
java.lang.String role,
java.lang.String dir,
java.lang.String name)
- Description copied from interface:
FileListener
- This method is called by the
FileManager
for each new file it creates.
- Specified by:
newFile
in interface FileListener
- Parameters:
id
- the file is related to this symbol id.type
- this indicates the type of the symbol. A constant
from Type
.role
- this describes the role the file plays. For example,
the file could be a STUBSRCS
file or a
IMPLSRCS
file. The role strings used
are determined by the backend.dir
- the path (relative or absolute) of the directory where
the file will be created.name
- the name of the file not including any directory
information. The complete name of the file should
be dir + name
.