VSSP packages: Preparing to Install
The following guidelines MUST be followed when preparing a
package for public installation in the VSSP group.
Directory structure
Give your package a 'nice' name and make a directory structure containing
sub-directories from the following list and any more you may need:
<![CDATA[
Xmgf/README - install notes
/src - source code
/inc - include files
/man - man pages
/doc - other documentation
/data - a >small< set of test data
/bin.sun4 - )
/bin.alpha - ) the respective binaries
/bin.mips - )
/lib.sun4 - )
/lib.alpha - ) the respective libraries
/lib.mips - )
/etc
/bitmaps
/examples
]]>
Notes
- It is probably easier if the same name is used for
package name, include file name,
directory name, library name and executable
name where possible.
- The src directory and a set of either bin or lib directories
are compulsory.
- If bin.x and lib.x dont exist they will be created by
the build script.
- Typically local copies of inc/man/lib.x/bin.x will be
maintained for each architecture, if you have additional
needs please spell them out in the README.
Makefiles
The src directory should contain Makefile(s) so that the
complete installation can be achieved by:
<![CDATA[
rsh beren; cd ...Xmgf/src; one_line_make_command
rsh melkor; cd ...Xmgf/src; one_line_make_command
rsh narya; cd ...Xmgf/src; one_line_make_command
]]>
The one_line_make_command may consist of separate commands separated by
semicolons. It should also find out the architecture
and load to the relevant lib.x bin.x directories. One way to do this
is to pass the architecture to the make command.
<![CDATA[
one_line_make_command = 'make ARCH=`arch`'
]]>
Important Notes
- There must not be pointers/links/references to libraries/data/anything
in anyones home directory or any other obscure part of the system.
Where possible use relative paths, to facilitate installation
elsewhere. If not, then a single prominent DIR=/vol/vssp/src/Xmgf/Xmgf
described in an imake or README.
- The top level README file should say how to install.
- The package MUST build successfully using ANSI headers. On the
sun4 architecture this means that headers in /vol/vssp/src/inc
take precedence over those in /usr/include. [vssp-build
does this automatically by aliasing gcc.]
- Your public version should link to other PUBLIC packages where
necessary, and it should link to the lib's for that architecture.
- For many packages one would like to have access to the functionality
thru function calls AND executables, try and provide both in a reasonable
way, also try and provide a single mini program that makes the call
so that the user can see what declarations will be needed.
- Try and achieve a "reasonable" level of modularity.
i.e. dont make libraries too big or too small.
- Your normal makefile may produce example executables
to demonstrate that the build has suceeded or for learning purposes.
The one-line-make should delete these, possibly with a make clean,
or rm ../bin/ex*.
- Under the present scheme we run the risk of name space pollution
for:
<![CDATA[
bin - binary names
lib - library names
- function names
inc - include file names
typedefs
macros
man - see above binaries, function names
So dont #include "image.h"
#include "defs.h"
void my_error(void);
int ludcmp(double *a, int n, int *indx, double *d); (from Num Recipes)
typedef struct {double x,y,z; } vector;
#define PI (22/7)
libgraph.a
edge
]]>
SOLUTION: try and give packages distinctive names or classes of
names. Try and keep some common text thru various
names, e.g.
<![CDATA[
function name GR_load_graph(),
typedef t_GR;
include file GR.h
]]>
A.Stoddart@ee.surrey.ac.uk
August 1994