[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: false positive result with 'make distcheck'
From: |
Ralf Wildenhues |
Subject: |
Re: false positive result with 'make distcheck' |
Date: |
Wed, 6 Sep 2006 07:27:24 +0200 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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