Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!labrea!decwrl!pyramid!prls!mips!dce
From: dce@mips.UUCP (David Elliott)
Newsgroups: comp.unix.wizards
Subject: Re: sources in a heterogenous enviroment
Message-ID: <613@quacky.UUCP>
Date: Thu, 20-Aug-87 12:35:12 EDT
Article-I.D.: quacky.613
Posted: Thu Aug 20 12:35:12 1987
Date-Received: Sat, 22-Aug-87 14:21:57 EDT
References: <390@sdics.ucsd.EDU>
Reply-To: dce@quacky.UUCP (David Elliott)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 74

In article <390@sdics.ucsd.EDU> wallen@sdics.ucsd.EDU (Mark Wallen) writes:
>With all the discussion about how to handle binaries
>for different processors in a heterogenous NFS environment,
>I have a related question.  How do you folks handle
>your source files?  For instance, we've got a fair
>amount of home-growed software and keep much of it
>on a NFS partition.  So far so good; I've won on
>both disk space and having to worry about multiple
>versions of source (there's only one now).  Here's
>the dinger--if I had just done a "make install" on
>my Vax system and turn around and to a "make install"
>on my Sun, there are probably a lot of Vaxish .o
>files hanging around.  Sure confuses make and the

I've seen 3 solutions to this type of problem, which not only
plagues NFS users, but also people with cross-compiler environments,
which are quite common in the early stages of most new systems
development projects.

1. Set up all makefiles so that "all" depends on "$(CLEAN)", which
   defaults to "clean". You can force it not to clean by saying

	make CLEAN= ...

   so it doesn't always clean. This solution isn't really great,
   but it works if you are fairly reasonable (like not aliasing
   make to "make CLEAN=").

2. Set up makefiles so that object files are stored in subdirectories.
   This either requires a mod to make to look in subdirectories, or
   requires more complicated makefiles. This also eats disk space
   pretty quickly.

3. Write a make front-end or front-ends that will create "semaphore"
   files, and have it do a "make clean" if the current state doesn't
   match what you are going to build.

   I've used two versions of this method. The first involves having
   a separate filename for each type of object you are building,
   such as "standard", "debug", "vax", "vaxdebug", and so forth.
   This works well if you have a limited set of things you are building.
   The other involves placing the values of the macros given on the
   command line and environmental parameters in a file. For example,
   if you are on a Sun and say

	femake CFLAGS=-g

   it should build a file containing "CFLAGS:-g" and "HOST-TYPE: sun",
   compare that against the file built for the previous build, and if
   it is different, do a "make clean", move the "new" data file to
   the "previous build" file, and execute the real make. If the files
   are the same, then no "make clean" is needed.

   You can also write a command called "make_same" that will run
   make with the same information as was previously used.

   If you want to keep multiple objects around, you can have the
   front-end move the objects to a subdirectory (using tar or
   cpio to preserve dates, and only if there is enough disk space),
   and have it be smart enough to look around for object files that
   match the build you are trying to do.

I could go on with this forever, but you get the idea.

The main thing I advise is that you try hard not to put all of
the work into the makefiles. I've seen some awfully complicated
makefiles in the systems I've worked with, and I'm convinced
that you can do everything you ever need with 4 targets: all
(make the commands locally), install (make the commands and
install them), clean (obvious), and generic (interface to shell
scripts that can do the tough stuff).

-- 
David Elliott		{decvax,ucbvax,ihnp4}!decwrl!mips!dce