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
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
|
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML>
<HEAD>
<TITLE>File Organization in Versions Icon Installations</TITLE>
<LINK REL="STYLESHEET" TYPE="text/css" HREF="istyle.css">
<LINK REL="SHORTCUT ICON" HREF="shortcut.gif">
</HEAD>
<BODY>
<P><A HREF="http://www.cs.arizona.edu/icon/"> <IMG SRC="wwwcube.gif"
ALT="[Icon home]" WIDTH=128 HEIGHT=144 BORDER=0 ALIGN=RIGHT> </A>
<H1> File Organization in Icon Installations</H1>
<P> Gregg M. Townsend
<BR> <SMALL> Department of Computer Science </SMALL>
<BR> <SMALL> The University of Arizona </SMALL>
<P> <SMALL> www.cs.arizona.edu/icon/v950/files.htm
<BR> Last updated November 16, 2009 </SMALL>
<!-- $Id: files.htm,v 1.19 2009/11/16 22:11:13 gmt Exp $ -->
<H2> Introduction </H2>
<P> Version 9.4 of Icon introduced several changes to the organization
of Icon's files under Unix and the methods for finding them.
These changes, which are described below, simplify the installation
and use of Icon.
<H2> Library procedure inclusion </H2>
<P> As Icon evolved, the procedures from the Icon program library
became more important to basic Icon programs, and vital to graphics
programs; yet the IPL had been treated as a separate product.
A complete Icon system required two downloads and two installation
efforts, with proper coordination.
<P> Now, the complete set of basic and graphics library
procedures is included with every binary Icon distribution.
Also present are the associated <CODE>$include</CODE> files
and a selected few programs from the library —
notably VIB, the visual interface builder.
<P> Source distributions of Icon include the full library,
which also continues to be available separately.
<H2> Installation directory structure </H2>
<P> An Icon binary distribution unpacks to produce an <CODE>icon</CODE>
directory containing <CODE>bin</CODE>, <CODE>lib</CODE>, <CODE>man</CODE>,
and <CODE>doc</CODE> subdirectories.
Building Icon from source produces these same directories.
<P> The <CODE>bin</CODE> directory contains executables of
<CODE>icont</CODE>, the Icon translator;
<CODE>iconx</CODE>, the Icon interpreter;
a few library programs including <CODE>vib</CODE>;
and <CODE>libcfunc.so</CODE>, the loadable C functions.
There is a symbolic link from <CODE>icon</CODE> to <CODE>icont</CODE>.
Files in this directory are system dependent.
<P> The <CODE>lib</CODE> directory holds <CODE>$include</CODE> files
and "ucode" (<CODE>.u1</CODE>/<CODE>.u2</CODE>) files of
program library procedures.
This directory is system independent.
<P> The <CODE>man</CODE> directory holds the Unix <CODE>man</CODE> pages
for <CODE>icon</CODE> and <CODE>icont</CODE>, and the <CODE>doc</CODE>
directory holds HTML (<CODE>.htm</CODE>) documentation files.
These directories are also system independent.
<P> This structure is similar to that of binary distributions of Icon 9.3.
The main difference is that the <CODE>lib</CODE> directory no longer holds
just a subset of the procedure collection, and the few files from
the former <CODE>include</CODE> directory have moved into <CODE>lib</CODE>.
<H2> Installation location </H2>
<P> The <CODE>icon</CODE> directory can be installed in any public or
private area as long as its internal structure is preserved.
When upgrading an existing Icon installation, replacing the previous
Icon directory with the new one may provide the smoothest transition.
Old Icon binaries will continue to function correctly with the new
interpreter.
<P> In order to consider packaging Icon binaries in Linux RPM files,
or other similar packages, it is necessary to define a "canonical"
location for installing Icon.
The suggested canonical system installation location for Icon is
<CODE>/opt/icon</CODE>.
The <CODE>/opt</CODE> directory is present today on most Unix systems and is
the location recommended by the emerging File Hierarchy Standard (FHS),
<A HREF="http://www.pathname.com/fhs/">www.pathname.com/fhs</A>.
<P> For convenience of use it may be desirable to provide symbolic
links from a directory such as /opt/bin or /usr/local/bin
to programs in the Icon <CODE>bin</CODE> directory.
If this is done, the list should include at least <CODE>icon</CODE>,
<CODE>icont</CODE>, <CODE>iconx</CODE>, and <CODE>vib</CODE>.
<H2> Automatic inference of <CODE>iconx</CODE> location </H2>
<P> Past versions of <CODE>icont</CODE> were configured to know
the location of <CODE>iconx</CODE> in order to embed this in
generated binaries.
The <CODE>iconx</CODE> location was configured by editing
<CODE>src/h/path.h</CODE> in source builds or by using the
<CODE>patchstr</CODE> utility to edit the <CODE>icont</CODE>
executable when installing a binary distribution.
<P> Now, <CODE>icont</CODE> deduces its own location,
and from this it infers the location of <CODE>iconx</CODE>
in the same directory.
No configuration of <CODE>icont</CODE> is needed, and the correct
path is embedded automatically, requiring only that
<CODE>icont</CODE> and <CODE>iconx</CODE> reside in the same directory.
<P> It is still possible to configure a fixed path in
<CODE>icont</CODE> using the <CODE>patchstr</CODE> utility.
If this is done, the configured path is used instead of the
inferred path.
<H2> Automatic search for iconx at execution </H2>
<P> The path that <CODE>icont</CODE> embeds in an Icon executable makes
binary distributions of Icon programs difficult because the embedded
path must be edited to match the installed location of <CODE>iconx</CODE>.
The <CODE>ipatch</CODE> utility performed this task when installing
binary distributions of Icon 9.3.
<P> Icon implements a simple search in the shell script that
heads each generated Icon executable.
The new header script searches for <CODE>iconx</CODE>
in these places:
<OL>
<LI> in the location specified by the ICONX environment variable
<LI> in the same directory as executing binary
<LI> in a location specified in the script itself
(as generated by <CODE>icont</CODE> or as patched later)
<LI> in the command search path ($PATH)
</OL>
<P> The second item is the key: If there is a copy of <CODE>iconx</CODE>
in the same directory as the executing program, it is found automatically
and used as the interpreter.
An Icon program can now be distributed in binary form
simply by including an <CODE>iconx</CODE> executable
in the same directory as the program executable.
<P> The <CODE>ipatch</CODE> utility has been modified to recognize
both old and new headers, and can still be used to edit the path
embedded in an Icon executable.
<H2> Automatic library access </H2>
<P> The ability to figure out its own location also lets
<CODE>icont</CODE> provide automatic access to library procedures.
The inferred location of the <CODE>lib</CODE> directory is implicitly
appended to the paths, if any, specified by LPATH and IPATH
environment variables.
To use only the standard library files, no environment variables
need be set.
<P> In a similar manner, <CODE>iconx</CODE> creates or alters the
FPATH environment variable before beginning execution of an Icon
program. This provides transparent access to the library's
loadable C functions without requiring explicit user action.
<H2> No Setup step </H2>
<P> With the changes above, the executable files in an Icon binary
distribution are ready for use without modification.
The annoying and error-prone Setup step that was necessary
with previous versions is no longer required.
Now, installation can be as simple as just unpacking the
tar file and adding its <CODE>bin</CODE> directory to the search path.
<P> <HR>
</BODY>
</HTML>
|
