Hi,
Tom Tromey <[EMAIL PROTECTED]> writes:
>>>>>> "Hari" == Raja R Harinath <[EMAIL PROTECTED]> writes:
>
> Hari> That code is there support non-srcdir builds in the face of
> Hari> 'make's with broken VPATH implementations. If you look at the
> Hari> Makefile, you'll see that it is checking to see whether 'make'
> Hari> said that the source file was in $(srcdir), and if not, the
> Hari> 'echo' supplies the $(srcdir).
>
> Actually it is even more subtle than that, I think.
>
> For explicit rules (not suffix rules), there are some macros like $<
> that we can't use.
But, we're talking about suffix rules like
.c.lo:
@AMDEP_TRUE@ source='$<' object='$@' libtool=yes @AMDEPBACKSLASH@
@AMDEP_TRUE@ depfile='$(DEPDIR)/$*.Plo' tmpdepfile='$(DEPDIR)/$*.TPlo' @AMDEP
BACKSLASH@
@AMDEP_TRUE@ $(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@
$(LTCOMPILE) -c -o $@ `test -f $< || echo '$(srcdir)/'`$<
We're fixing up what 'make' told us the source file was, and we ask
'make' about the source file name only in a suffix rule.
> For some versions of make, these macros only have values in suffix
> rules. So we have to do srcdir-searching by hand in explicit rules
> for GNU make, so that the code will continue to work in a
> srcdir-build context for vendor makes.
Why would one do this the complicated way? You already know
explicitly where source file is, so why would you fix it up with the
shell fragment above?
foo.lo: foo.c
$(LTCOMPILE) -fsomething-special -c -o foo.lo $(srcdir)/foo.c
> I don't like this, but I don't see what we can do about it.
> Even finding a way to reject non-srcdir builds for non-GNU make won't
> help here.
I agree.
- Hari
--
Raja R Harinath ------------------------------ [EMAIL PROTECTED]
"When all else fails, read the instructions." -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing." -- Roy L Ash
