Path: news1.icaen!news.uiowa.edu!feeder.chicago.cic.net!su-news-hub1.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.bbnplanet.com!news.mathworks.com!usenet.logical.net!news.dal.ca!newsflash.concordia.ca!canopus.cc.umanitoba.ca!tribune.usask.ca!rover.ucs.ualberta.ca!alberta!glyn
From: glyn@cs.ualberta.ca (Devin Reade)
Newsgroups: comp.sys.apple2.programmer
Subject: Re: dmake questions
Date: 11 May 1997 19:14:26 GMT
Organization: Myrias Research Corporation
Lines: 97
Message-ID: <5l55qi$lrh$1@scapa.cs.ualberta.ca>
References: <5l0r9s$fut$1@News.Dal.Ca>
NNTP-Posting-Host: menaik.cs.ualberta.ca

In article <5l0r9s$fut$1@News.Dal.Ca>,
Michael Hackett <at217@chebucto.ns.ca> wrote:
>
>1) How do you do recursive makes, e.g. a central makefile that builds
>components in separate subdirectories each with their own makefiles?
>I haven't had much luck with this.

First of all, I don't recommend doing it with the current dmake on
the IIgs; dmake is using too much stack space to make recursive
makes feasible.

However, the rules for setting it up would be something like this.
Assume that you have subdirectories "subdir1" and "subdir2".  Within
each, you have a target named "build".  If you have a top-level makefile
like the following, you can make "build" in all directories by typing
'dmake build' at the top level:

============= makefile start
SUBDIRS = subdir1 subdir2

build: $(SUBDIRS)

..PHONY: $(SUBDIRS)

$(SUBDIRS):
	cd $*; $(MAKE) build
============= makefile end

In practice (with the current IIgs dmake) I don't tend to use a 
makefile at the top level.  Instead, I have a kludgy work-around
where I have a shell script similar to the following.  It's ugly,
but given that gsh doesn't have flow control, it seems the best
method at the moment.

============= makebuild end
set PWD=/current/full/directory/name
set TARGET=build

cd subdir1; dmake $TARGET; cd $PWD
cd subdir2; dmake $TARGET; cd $PWD
============= makebuild end

>2) Does anyone have any recommendations on building targets from
>two distinct sets of files, as often needs to be done with IIgs
>programs (data and resource forks)?

It sounds like your problem is that you want to create a program
that has both data and resource forks, but you don't like recompiling
the resource fork every time you want to relink your program, correct?

Do do this, I use the following setup:

=================== makefile start
OBJS	= one.o two.o three.o four.o

prog: $(OBJS) prog.r
	$(CC) -o $@ $(LDFLAGS) $(OBJS) $(LDLIBS)
	copyfork prog.r $@ -r
=================== makefile end

Using the default rules in /usr/local/lib/startup.mk, dmake will
only create the resource file "prog.r" if "prog.rez" is out-of-date.
"prog.rez" is your resource source file.  Copyfork is a utility
that will seletively copy either or both forks of a file.  It is 
available on the Golden Orchard CD, and I think it has also been uploaded
to ground/caltech.  If you can't find it, contact me in email, preferably
at the address in my .sig.

BTW, it's important not to use $< in the recipe lines in this case
since you want to treat the object and resource files separately.

>Worse is the problem I ran into where the directory
>search feature of dmake (which I like a lot -- I keep all my
>object and macro files in subdirectories separate from the source,
>for example) is disabled because I have to repeat the object files
>list in the link command instead of using something like "$<" which
>adds the correct directory name to each file.

Here's one work-around that has a minimum of overhead when all targets
are up-to-date.  Define an extra target (in this example, "build")
that handles the resource copy step.  If "prog" is the name of your
program (minus resource fork), and assuming that it's building fine
with your source/object files in separate directories, then ...

	build: prog prog.r
		copyfork prog.r prog -r

If you want to eliminate the copy when everything is up-to-date, you
can do it at the expense of having an extra copy of the program kicking
around:

	prog2: prog prog.r
		cp prog $@
		copyfork prog.r $@ -r

--
	Devin Reade	gdr@myrias.com
