ado@elsie.UUCP (Arthur David Olson) (10/18/88)
What is the latest thinking on the directory that non-vendor executables should go in? I've seen some packages that drop them into /usr/local and others that drop them into /usr/local/bin. If you have insights on the matter, I'd appreciate hearing from you by mail. -- ado@ncifcrf.gov ADO is a trademark of Ampex.
lamy@ai.utoronto.ca (Jean-Francois Lamy) (10/20/88)
In article <8504@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes: >What is the latest thinking on the directory that non-vendor executables >should go in? I've seen some packages that drop them into /usr/local >and others that drop them into /usr/local/bin. Current trends go towards /local/bin or /usr/local/bin. Our local preference, along the lines of SunOS4.0, is to have ...local/{bin,lib,share}. Our rationale for the split is as follows: share: architecture independent stuff config/data/docs you don't want to replicate. lib: architecture dependent (*) libraries and executables bin: architecture dependent (*) executables. This goes in user's path. (*): we replicate shell/awk/perl/... scripts, because they are typically installed by the same makefile that created binary executables and we feel that using an interpreter instead of a compiled language is merely an implementation choice (we often mutate programs from an sh prototype to a C version. A good rule of thumb is to keep in mind that even if you don't have a mixed-architecture environment *now*, you may have one soon. So write your Makefiles and #defines with an explicit directory for architecture independent configuration data and aux. files. It costs little to simply define it to be the same as the architecture dependent one if you so wish, but it will make life much easier later. > If you have insights >on the matter, I'd appreciate hearing from you by mail. News provides a better soapbox :-). Sure wish everyone who posts software was stuck in an heteregeneous environment (there are Sun 2, 3 and 4, MIPS and (gak) Ultrix uVaxen around here, all trying to run off the very same source trees). After "the world is a Vax" , is now time to stamp out the single-architecture myth. Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4
mtr@ukc.ac.uk (M.T.Russell) (11/01/88)
In article <88Oct19.153216edt.45@neat.ai.toronto.edu> lamy@ai.utoronto.ca (Jean-Francois Lamy) writes: >A good rule of thumb is to keep in mind that even if you don't have a >mixed-architecture environment *now*, you may have one soon. So write your >Makefiles and #defines with an explicit directory for architecture independent >configuration data and aux. files. We have a scheme for building binaries for multiple architectures in a single NFS mounted source tree which I haven't seen described elsewhere. We have a make variable (M) set to a name for the architecture/OS combination, which is then used in the makefile to name the architecture specific .o files and binaries. Makefiles look roughly like: .SUFFIXES: .$Mo .c.$Mo: $(CC) -c $(CFLAGS) $*.c mv -f $*.o $*.$Mo OBJS = bar.$Mo baz.$Mo foo: $Mfoo $Mfoo: $(OBJS) $(CC) -o $@ $(OBJS) So if M is set to "sun3_", then bar.sun3_o and baz.sun3_o are linked to build sun3_foo. M can obviously be made more specific (e.g. "sun3_sunos4_"). This scheme has several advantages over the shadow tree of symlinks method: - you always get the right binary for the right architecture. - binaries for multiple architectures can exist simultaneously in the same source directory - all you have to do to add a new architecture is define a new name for it in $M - no shadow tree of symlinks to maintain Of course with an existing source tree it has the disadvantage that you'd have to hack all the makefiles - we only use it for our own projects. One problem is that you can't have two makes running simultaneously on two different architectures as the intermediate .o files can clash. What I'd like to write for the compilation rule is .c.$Mo: $(CC) -c $(CFLAGS) -o $*.$Mo $*.c but unfortunately the C compilers don't allow -o with -c. M is set in the environment, usually via .login. Locally we have a machinetype command, and a line setenv M `machinetype` in .login. If your version of make doesn't import environment variables, you have to install a wrapper, e.g. #! /bin/sh exec /bin/make "M=$M" "$@" Mark Russell mtr@ukc.ac.uk