Mail Archives: djgpp/2000/07/06/05:19:34
On Wed, 5 Jul 2000, Tim "Zastai" Van Holder wrote:
> > You need to put "SHELL = /bin/sh" somewhere in the Makefile, and then
> > Make will Do The Right Thing.
> Apparently, not all the time... In automake 1.4a, a script (depcomp) is used
> to generate dependencies while also compiling the relevant file; it gets
> invoked like this:
>
> .c.o:
> source='$<' object='$@' libtool=no \
> depfile='$(DEPDIR)/$*.Po' tmpdepfile='$(DEPDIR)/$*.TPo' \
> $(CCDEPMODE) $(depcomp) \
> $(COMPILE) -c -o $@ `test -f $< || echo '$(srcdir)/'`$<
>
> with depcomp = $(SHELL) $(srcdir)/depcomp
>
> With the DJGPP port of make, this does not work (the script never sees the
> variables).
Does Make invoke Bash to run this command? If it does, Make works
correctly: all Make is responsible to do in this case is (a) to detect
that this command requires a shell, and (b) to invoke Bash given the
"SHELL = /bin/sh" line. Anything else is up to Bash and the commands
it invokes.
> As a workaround in my port (still under development, although I
> may release it soon), I enclosed the entire statement in $(SHELL) -c
> "<statement here>". This did work (although makefiles using quotes in their
> compilation switches now need patching). I'm at a loss as to why this is; if
> the same method of invocation is used in a script in bash, it works fine.
You will need some more digging to find out what happens inside that
rule. Trying a simpler command or a different shell script instead of
depcomp might shed some light.
I vaguely remember that someone reported a similar problem on
djgpp-workers a few months ago, so you might search the mail-archives
URL at DJ's server. IIRC, the conclusion in that thread was that it
is some strange problem in Bash, although I don't think I've seen a
definitive analysis.
> So my guess is that it's somehow make's fault.
Any facts to back up this guess? ;-)
- Raw text -