Path: utzoo!attcan!uunet!mcvax!ukc!eagle.ukc.ac.uk!mtr
From: mtr@ukc.ac.uk (M.T.Russell)
Newsgroups: comp.unix.questions
Subject: Re: /usr/local vs. /usr/local/bin
Message-ID: <5757@eagle.ukc.ac.uk>
Date: 31 Oct 88 19:09:06 GMT
References: <88Oct19.153216edt.45@neat.ai.toronto.edu>
Reply-To: mtr@ukc.ac.uk (M.T.Russell)
Organization: Computing Lab, University of Kent at Canterbury, UK.
Lines: 69

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