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'|[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".
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
