Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!ncar!gatech!udel!rochester!kodak!ispd-newsserver!ism.isc.com!bud.sos.ivy.isc.com!willcr
From: willcr@bud.sos.ivy.isc.com (Will Crowder)
Newsgroups: comp.unix.questions
Subject: Re: Makefile for Compressed files (.o.Z)
Message-ID: <1991Apr11.180527.21674@ism.isc.com>
Date: 11 Apr 91 18:05:27 GMT
References: <1991Apr8.194733.17653@berlioz.nsc.com>
Sender: usenet@ism.isc.com (Ism Usenet News)
Reply-To: willcr@ivy.isc.com
Followup-To: comp.unix.questions
Organization: Interactive Systems Corp.
Lines: 60

In article <1991Apr8.194733.17653@berlioz.nsc.com>, nelson@desktop.uiuc.edu
(Taed Nelson) writes:

|> I've been trying to create a makefile which automatically uncompresses
|>   the appropriate file when it is needed.
|> 
|> It seems that one would want to define a rule to take *.o.Z files and
|>   make them into *.o files:
|> 	.o.Z.o:
|> 		uncompress $<
|>   but I think that the multiple '.'s in the rule confuses MAKE.  I
|>   tried adding .o.Z to the SUFFIXES list, but that doesn't seem
|>   to help at all.

For most makes, the multiple '.'s shouldn't have anything to do with it.
Most makes don't use the existence of a '.' to determine what a suffix is,
they use the longest matching suffix from the .SUFFIXES list.  This is a 
common misconception.

What problems are you seeing, and what system is this running under?  I
tried the following under SunOS 4.1.1:

.SUFFIXES: .o.Z .o .c

.o.Z.o:
	uncompress $<

.c.o:
	cc -c $< -o $@

I ran make with the -r switch to keep it from reading in default rules.  (More
on that later.)  If both x.o.Z and x.c existed, the .o.Z.o rule was performed.
Same if just the x.o.Z file existed.  If only x.c existed, however, the
.c.o rule was performed.  This seems like reasonable behavior, given the
order in which the suffixes were given for the .SUFFIXES special target.

Since your make is probably reading in a default makefile (or has built-in
defaults), the .o.Z suffix gets appended to the end of the list.  This means
that if x.c exists, and regardless of whether x.o.Z exists, the .c.o rule
will be used to build it.  Is that the behavior you're seeing?  If so,
you'll need to clear the suffixes list (by placing a .SUFFIXES: target by
itself in your makefile) and then define the suffixes in the order you
want them processed.

If your make is indeed getting confused by multiple '.'s in the the .o.Z
suffix, get a new one.  It's horribly broken (IMHO).

|> It seems that this must have been done before -- anyone know how
|>   to do it?  An example will suffice.
|> 
|> Thanks!

You're welcome...hope this helps,

Will

--------------------------------------------------------------------------------
Will Crowder, MTS            | "That was setting #1.  Anyone want to see
(willcr@ivy.isc.com)         |  setting #2?"
INTERACTIVE Systems Corp.    |		-- Guinan