Date:	Fri, 23 Oct 1998 17:10:26 +0200
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Message-Id:	<199810231510.RAA20775@acp3bf.physik.rwth-aachen.de>
To:	djgpp AT delorie DOT com
Subject:	Re: Recursive make: portable technique?
Newsgroups:	comp.os.msdos.djgpp
Organization:	RWTH Aachen, III. physikalisches Institut B
X-Newsreader:	TIN [version 1.2 PL2]
Reply-To:	djgpp AT delorie DOT com

In article <362FF086 DOT BDA6266C AT montana DOT com> you wrote:
> On a straight DOS system with only command.com for a shell, make will
> fail after

> cd ../new_dir; $(MAKE) 

Of course it will. How on earth do you expect DOS's 'cd' command to
understand *forward* slashes? 

> I found that doing an explicit  cd ../original_dir fixed the problem,
> and there were a few exchanges about this in the archives that indicated
> this was the case. 

Actually, there is no really portable method for doing this. In a
Unixy environment, every 'make' command line would be executed by a
separate sub-shell, and thus a single 'cd' command doesn't do
anything.

OTOH, 'make' behaviour isn't all to portable, anyway, so my recommendation
would be: required GNU make to be used, and use its

	$(MAKE) -C ../original

feature for recursion. Works perfectly, and without any changes, for all
platforms with a reasonably well-ported GNU make.

> I ran a small test using this hack with bash available, and pointed to
> by SHELL, and it still seemed to work.

And in a true Unix environment, it definitely wouldn't work at all.
The main difference is that the 'current working directory' has a
*totally* different meaning on DOS and Unix: in DOS, there's exactly
*one* working directory per drive letter, and it's the same
system-wide. On Unix, every process has it's own working directory.

--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -