Purpose: to contain discussion relating to an installation directory structure that is recommended for people writing tcl extensions or applications. Note that the directory structure here refers to the final disposition directory, as opposed to the directory structure within the source archive. There might even be some cross over with the directory structure of a [starkit] or similar construct. [LV] Jump right in and add info as you see needed: ---- By default, extensions should use two main groups of directories for installing things, one for architecture-independent files, and one for architecture-dependent files. '''--prefix''' specifies the directory of the architecture-independent files (e.g. Tcl scripts, header files, documentation) and is conventionally ''/usr/local'' by default. Beneath this directory, the following directories are usually defined: '''include''': Directory into which one installs the header file(s) needed when writing code against a library. This is header files for C/C++/etc., and not Tcl code '''lib''': Directory into which Tcl-only extensions are installed, each into their own directory. '''lib'''/''extension-version.level'': Directory for ''pkgIndex.tcl'' files, tcl files, etc. '''bin''': Place to install Tcl-only applications and script demos and examples. '''man''': Place to install nroff manual pages. '''share''': Place to install miscellaneous other files, such as HTML pages or data files. '''--exec-prefix''' specifies the directory where architecture-dependent files (binary extensions, etc.) are to be installed. '''lib''': Directory into which binary extensions and their ''pkgIndex.tcl'' are installed, each into their own directory. '''lib'''/''extension-version.level'': Directory for ''pkgIndex.tcl'' files, .so/.dll files, static archives (.a, .lib), etc. '''bin''': Directory where binary applications and demos are installed. ---- Note that the '''--exec-prefix''' defaults to the same value as '''--prefix''' ---- [jenglish] I find it works better to put the entire package runtime in a sibling directory of '''info library'''. This is ''usually'' the same as ''${libdir}'', but not always. Joe, into which of the above directories are you referring? ${prefix}/library? Splitting up architecture-dependant (e.g. shared libraries) and architecture-independant (e.g., scripts) parts makes it more difficult for the former to locate the latter. ---- It is the eternal difficulty of keeping parallel versions in sync versus keeping a single copy of sharable code and a binary for each platform that causes me to recommend considering the above structure. Also, are you thus recommending that one put the name of the platform into the ''name'' of the library? How about a specific example to help me visualize your suggestion? For instance, the description above allows either of the following approaches: /usr/local/bin/tkconsole /usr/local/include/tcl.h /usr/local/include/tk.h /usr/local/lib/BWidgets1.3/pkgIndex.tcl /usr/local/sun4/bin/wish8.4 /usr/local/sun4/lib/tcl8.4/pkgIndex.tcl /usr/local/sun4/lib/tcl8.4/libtcl8.4.so /usr/local/sun4/lib/tk8.4/pkgIndex.tcl /usr/local/sun4/lib/tk8.4/libtk8.4.so /usr/local/hpux5/bin/wish8.4 /usr/local/hpux5/lib/tcl8.4/pkgIndex.tcl /usr/local/hpux5/lib/tcl8.4/libtcl8.4.so /usr/local/hpux5/lib/tk8.4/pkgIndex.tcl /usr/local/hpux5/lib/tk8.4/libtk8.4.so /usr/local/redhat7.2/bin/wish8.4 /usr/local/redhat7.2/lib/tcl8.4/pkgIndex.tcl /usr/local/redhat7.2/lib/tcl8.4/libtcl8.4.so /usr/local/redhat7.2/lib/tk8.4/pkgIndex.tcl /usr/local/redhat7.2/lib/tk8.4/libtk8.4.so /usr/local/share/html/tutorial/file1.html or, if you had only one platform: /usr/local/bin/tkconsole /usr/local/bin/wish8.4 /usr/local/include/tcl.h /usr/local/include/tk.h /usr/local/lib/BWidgets1.3/pkgIndex.tcl /usr/local/lib/tcl8.4/libtcl8.4.so /usr/local/lib/tcl8.4/pkgIndex.tcl /usr/local/lib/tk8.4/libtk8.4.so /usr/local/lib/tk8.4/pkgIndex.tcl /usr/local/share/html/tutorial/file1.html ---- Note that right now, I don't know whether the [TEA] structure follows the above directory structure or not. The reason I say this is that when I look at my install directory, I find some .a and .so files being directly installed under ${exec_prefix}/lib/ and some being installed under ${exec_prefix}/lib/{extension}*/ . The downside of installing ''everything'' under its own directory is that link statements become more complex. The upside is consistency in the way that the install software gets written, the pattern that new packages follow, etc.. ---- What are your thoughts about installed extensions having version numbers in their directory names? Some people use multiple versions of an extension to keep from having to relink compiled language based programs. Other people see no reason to distribute anything more than one version and just expect people to install things into seperate trees if parallel versions need to be maintained. ---- What about demos? I would prefer to see demo executables be installed in $prefix/bin, instead of the current practice of some extensions of putting them into $prefix/lib/extension$version.$level/demos or whatever . ---- ''[CL] noted in [the comp.lang.tcl newsgroup] on the problem of where to put config files:'' What a mess. Someone ought to go off for a few years, and create a useful solution to such common and stupid deployment problems. Maybe it should be called TclKit, or perhaps called that, but renamed to [StarKit]. Just think if it were portable, too! The masses would re- joice. ''to which [BBH] replied:'' Amen, Brother Laird! (NB. A [Starkit] is a single file per app that contains all configuration, source, binaries, etc.) Installation is by copying, deinstallation by deleting.