Re: false positive result with 'make distcheck'

[Harlan Stenn]

Hi Ralf,

> > > 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.

OK, I know I had good reason to add $(srcdir)/ to some targets
(dependencies?) and at the time, I did not add it to others (because at
the time, "things worked").

I consequently got screwed with both FreeBSD and Solaris make, for
different reasons.

The problem was solved when I consistently added $(srcdir)/ before every
instance of "foo" for targets, dependencies, and in rules (the latter
was because of Solaris 'make').

> > 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.

'k.

> 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?

Probably nothing - I may have read what you wrote "differently" from
what you intended.  I was concerned about your first case - if somebody
goes to the trouble of putting a $(srcdir)/ on a target or a dependency,
they need to be either "most everywhere" or nowhere.

This may not be true, but it is a rule I currently accept.

H