Re: false positive result with 'make distcheck'

[Ralf Wildenhues]

Hello Harlan,

* Harlan Stenn wrote on Tue, Sep 05, 2006 at 10:00:55PM CEST:
> Ralf writes:
> > 
> > Two ways to get out of this:
> > - do not stick $(srcdir)/ in front of the prerequisites.  For example,
> >   this should work portably (if you take care not to stick $(srcdir)/
> >   elsewhere before the *.in files):
> > 
> > rpmbuildupdate: rpmbuildupdate.in
> >     perl -pi -e s'|address@hidden@|$(sysconfdir)|' \
> >       < $(srcdir)/rpmbuildupdate.in > $@
> > 
> > rpmbuildupdate.comp: rpmbuildupdate.comp.in
> >     perl -pi -e s'|address@hidden@|$(sysconfdir)|' \
> >       < $(srcdir)/rpmbuildupdate.comp.in > $@
> > 
> > (Note that even Solaris make would not VPATH-rewrite the rule, since the
> > string `rpmbuildupdate.in' is not surrounded by white space in the rule.)
> 
> This way will not work if one wants the generated Makefiles to be useful
> on several non-GNU versions of "make".

Yes it will.

> As I recently learned, if one uses $(srcdir)/foo as a target or a
> dependency, one must use it in all places "foo" is referenced (including
> on the command line rule of a target, or Sun's "make" (for example) will
> do Interesting things.

Yes, I think I mentioned that in the message you quote.  The above will
work with Solaris make: all instances of `rpmbuildupdate.in' in the
rule are _not_ surrounded by whitespace: there is a `/' right before
them.  So they are not rewritten in this case.

But you are right that all instances of `rpmbuildupdate.in' in targets
or prerequisites should also not be prefixed with `$(srcdir)/' so other
make implementations won't think they are two different things (and note
that $(EXTRA_DIST) occurs as prerequisite in a generated rule).  I think
I noted that too, though.

What am I missing?

Cheers,
Ralf