1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
Modules can import module-compiled system header files (cf. section
ref(MODHDR)) and/or module-compiled header files of locally developed libraties
(cf. section ref(LOCHDR)).
What if a library's design merely uses modules? In that case the library must
make available its module-compiled interface files (i.e., tt(.gcm) files) to
its users. Copying the library's tt(.gcm) files to the tt(gcm.cache)
sub-directory of a using project is not necessary (and probably a bad design
anyway, since modifications of the library's tt(.gcm) files will not be
noted), but soft-links should be used. However, often modules import other
modules or partitions, and consequently such library-modules in turn may
depend on other modules (or partitions). When a project must import a
library's module not only the module's tt(.gcm) file must be available but
also (recursively) the module/partition tt(.gcm) files that module depends
on.
As an illustration consider the situation where a project defines three
modules: tt(Module1, Module2,) and tt(Module3. Module1) imports tt(External),
which is a module offered by some library; tt(Module2) imports
tt(Module1), and tt(Module3) imports tt(Module2) (cf. figure ref(threemods)).
figure(modules/threemods)
(Three modules and an external module)
(threemods)
The tt(External) module doesn't belong to the current project, and so the
tt(External.gcm) file lives elsewhere. When constructing the project its
tt(gcm.cache) directory must make tt(External.gcm) available. This is realized
by defining a soft-link to the actual location of tt(External.gcm). But in
addition soft-links to the modules/partitions imported by tt(External.gcm)
must be made available in the project's tt(gcm.cache) sub-directory.
The bf(icmodmap)(1) support program can be used to determine and to satisfy
the requirements of externally defined modules.
COMMENT(examples/externaldemo)
To determine the modules' dependencies tt(icmodmap) is called in the
project's top-level directory specifying its tt(--dependencies) (or tt(-d))
option. It shows the dependencies amount the modules and reports an error as
the module tt(External) isn't found:
verb( [Error 1] 1 UNKNOWN module
Dependencies:
LOCAL module Module1
imports UNKNOWN module External
UNKNOWN module External
LOCAL module Module2
imports LOCAL module Module1
LOCAL module Module3
imports LOCAL module Module2
)
And indeed, there's an error: the tt(External) module wasn't developed in
the context of the current project. It's defined in an external library,
offering its module/partition compiled interface units to its users. By
informing tt(icmodmap) where the external tt(.gcm) files are located the error
is solved. The relative or absolute path to the directory containing the
library's tt(.gcm) files is either specified as a command-line option or it's
specified in a file. Either of these can be passed to tt(icmodmap) using its
tt(--extern) (or tt(-e)) option. E.g., if the library's tt(.gcm) files are in
tt(/tmp/library/gcm.cache) then by calling
verb(
icmodmap -d -e /tmp/library/gcm.cache)
the error disappears and tt(icmodmap) reports:
verb( Dependencies:
LOCAL module Module1
imports EXTERN module External
EXTERN module External
LOCAL module Module2
imports LOCAL module Module1
LOCAL module Module3
imports LOCAL module Module2
)
specifying tt(--extern) also defines the soft-links to the external
modules: the project's tt(gcm.cache) sub-directory now contains the soft-link
verb( External.gcm -> /tmp/library/gcm.cache/External.gcm)
Now that the requirements of the project's module interface files are all
satisfied they can be compiled (they are compiled by tt(icmodmap) if the
tt(-d) option isn't specified), followed by the compilation of the project's
remaining source files. Finally, all object files can be linked to the used
object files of the external library in the usual way (specifying, e.g., the
linker's tt(-L) and tt(-l) options).
|
