> From: fox_at_GRAPHICS.CS.NYU.EDU (David Fox)
> Subject: Distributing extensions to STk
>
> It is quite easy to extend STk using the instructions in the
> documentation. What is not so easy is writing and distributing an
> extension to STk in such a way that it is easy for other people to
> take and install, and in such a way that it is easy to maintain the
> software for multiple architectures on the same file system. There
> are several reasons for this:
This is the kind of thing I do a lot, and I strongly agree it is
needed.
> 1. The standard install procedure doesn't install all the necessary
> librarys, only libstk.a. It should install libtk.a, libtcl.a, and
> libgmp.a as well, but to avoid conflicts with the regular tk and
> tcl libraries these should be merged into libstk.a.
Very true. The merging is highly questionable though. The normal way
to do this would be to not hide what libs are needed by extenders. If
you merge, then you tie me into a specific release of gmp or tk, with
all the bugs that may entail. It is also a fairly large waste of
space. No.. better to let the programmer worry about his own linking.
> 2. The stk include files are not placed in the installation directory;
> these are needed to compile extended applications.
Yup.
> 3. The stk binary, stk-bin, is put in the same directory regardless of
> what type of CPU it was compiled for, *and* its path is hard coded
> into the launcher shell file.
This is somewhat fine. Hardcoded paths are a fact of life. and its
certainly 'safer' than using $PATH. If you dont like the path name,
"Why did you install it there?".
> I would recommend installing the libraries and stk-bin executable in
> a subdirectory of /usr/local/lib, using uname to construct a name
> which is machine dependent, e.g.
>
> libdir=/usr/local/lib/`uname -m`-`uname -s`
If you were going to do this, you should use $libdir/stk/$archtype.
Placing the arch information directly under 'lib' would be misleading
& might lead to obscure conflicts. Better to claim your own name space
with a 'stk' dir & then do what you will under that.
> Uname can then be used in the stk shell script to locate the correct
> subdirectory. Also, the include files should be installed in
> /usr/local/include/stk. This would make my life easier - as it is
> I have to repackage STk for distribution with my software.
I dont think that coding in architecture specific information into
programs that really dont care about fine granularity is a good idea.
The gross management of SPARC binaries for SPARC, and x86 binaries for
x86 is an administrative issue that is MOST easilly addressed if
programs dont try to help too much. Certainly one cannot look to all
programmers in the world to agree on a system for doing this.
What one can reasonably expect if for an install to say EXACTLY what
it will do. It is very important that install procedures give you a
system that depends in no way on the source directory for any reason,
such as writing extensions. Providing multiple install targets so
those who dont care dont get everything is fine. I cant begin to tell
you how annoying it is to manage a huge number of programs and
utilities, and have a few of them take up 90% of your time because you
have to track down what objects are needed, and what header files are
needed to write extensions. Python & Perl4 are both prime examples.
Lastly.. one of the best things a programmer can do is actually
install his code FROM the distribution, and use it that way. The
stupidest errors get by testing because they are flaws in the
distribution system, not the 'real' code.
--
John Redford (AKA GArrow) | 3,600 hours of tape.
jredford_at_lehman.com | 5 cans of Scotchguard.
Received on Mon Nov 14 1994 - 15:22:42 CET