Ralf writes: ,,,
> Now, even when you stick "$(srcdir)/" in front of the prerequisites, > still VPATH searching applies. Since source tree of the distcheck > source (that below /tmp/rpmbuildupdate-0.7/rpmbuildupdate-0.7) does > not contain the *.in files, but VPATH contains "..", the `make' executed > inside the directory /tmp/rpmbuildupdate-0.7/_build finds the file > ../../rpmbuildupdate.in.in > > and happily uses them; that is: the second "../" is your "$(srcdir)/", > and the first "../" is the result from make's VPATH search. > > ... > > 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'|[EMAIL PROTECTED]@|$(sysconfdir)|' \ > < $(srcdir)/rpmbuildupdate.in > $@ > > rpmbuildupdate.comp: rpmbuildupdate.comp.in > perl -pi -e s'|[EMAIL PROTECTED]@|$(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". 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. > - Try issing distcheck from a VPATH build itself. For example, > after the exact steps printed at the beginning of this mail, do: > > make distclean # needed so configure from VPATH will not complain > mkdir ../build > cd ../build > ../rpmbuildupdate-0.7/configure > make distcheck # fails This seems better, from what I have seen. H
