Check-in [dc273ce4f7]
Overview
Comment:Updated README
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: dc273ce4f75c95f2061fb4a9ee1cc21f47dd79c3
User & Date: rkeene on 2010-09-26 04:43:56
Other Links: manifest | tags
Context
2010-09-26
04:44
Reverted cleanup of tclExecutableName check-in: 0368915b0d user: rkeene tags: trunk
04:43
Updated README check-in: dc273ce4f7 user: rkeene tags: trunk
04:43
Updated to return in failure if we fail to properly install check-in: bdcfd6df7f user: rkeene tags: trunk
Changes

Modified README from [5eafd68bb0] to [bcca4a4827].

104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
	3. */build.sh installs software into "inst" (run-time + compile-time)
	4. */build.sh installs run-time software into "out", this will be
	   included in the Tclkit as if it were the root directory of the
	   Tclkit (combined with other "out" directories)
	5. kitsh/build.sh compiles a "main" function and links all the built
	   libraries together into an executable
	6. kitsh/build.sh combines all the "out" directories into one
	7. kitsh/build.sh creates a Metakit database from the combined
	   directories and appends that to the compiled executable using:
		a. A Tclkit found in the environment variable "TCLKIT" (tclkit
		   if unset) if it is functional; or
		b. The built kit itself (does not work for cross-compiling)

Details:
	The general mechanism that enables a Tclkit to operate is a small Tcl







|







104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
	3. */build.sh installs software into "inst" (run-time + compile-time)
	4. */build.sh installs run-time software into "out", this will be
	   included in the Tclkit as if it were the root directory of the
	   Tclkit (combined with other "out" directories)
	5. kitsh/build.sh compiles a "main" function and links all the built
	   libraries together into an executable
	6. kitsh/build.sh combines all the "out" directories into one
	7. kitsh/build.sh creates a Metakit or Zip database from the combined
	   directories and appends that to the compiled executable using:
		a. A Tclkit found in the environment variable "TCLKIT" (tclkit
		   if unset) if it is functional; or
		b. The built kit itself (does not work for cross-compiling)

Details:
	The general mechanism that enables a Tclkit to operate is a small Tcl
158
159
160
161
162
163
164




165
166
167
168
169
170
171
172
173
the individual projects together into a single executable.  Its build script
does not create an "inst" or an "out" directory because it is not a library.
Instead, it collects all the other project's "out" directories into a single
directory (starpack.vfs), as well a static file (boot.tcl).  It then compiles
the source code, and then installs the Metakit database containing the VFS
onto the resulting executable.





To create the Metakit database, one of two Tclkits is used (tried in this
order):
	1. The Tclkit specified by the TCLKIT environment variable (or
	   "tclkit" if that variable is not set) if it is functional; or
	2. The built Tclkit itself

The second method will not work if the built Tclkit is not executable on the
current platform (i.e., in the case of cross-compilation) and so it may be
necessary to bootstrap a runnable Tclkit first.







>
>
>
>
|
|







158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
the individual projects together into a single executable.  Its build script
does not create an "inst" or an "out" directory because it is not a library.
Instead, it collects all the other project's "out" directories into a single
directory (starpack.vfs), as well a static file (boot.tcl).  It then compiles
the source code, and then installs the Metakit database containing the VFS
onto the resulting executable.

If the "mk4tcl" project fails to build (or is not requested to be built),
the rest of the project will be built using zip files instead of Metakit
databases.

To create the Metakit database (if needed), one of two Tclkits is used (tried
in this order):
	1. The Tclkit specified by the TCLKIT environment variable (or
	   "tclkit" if that variable is not set) if it is functional; or
	2. The built Tclkit itself

The second method will not work if the built Tclkit is not executable on the
current platform (i.e., in the case of cross-compilation) and so it may be
necessary to bootstrap a runnable Tclkit first.