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