[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Built sources and make distcheck

From: Allan Caffee
Subject: Re: Built sources and make distcheck
Date: Tue, 24 Feb 2009 18:43:02 -0500
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

On Mon, 23 Feb 2009, Tavian Barnes wrote:
> 2009/2/23 Ralf Wildenhues <address@hidden>:
> [...]
> > generated.c can live in the source or in the build tree.  But given that
> > different make implementations have slightly different VPATH semantics,
> > it may be useful to require it to always live in the source tree;
> > further, it may be useful to update it lazily (this shouldn't matter for
> > read-only trees iff your dependencies are set up correctly, but it
> > should make for faster rebuilds):
> >
> > $(srcdir)/generated.c: generate.c
> >        ./generate$(EXEEXT) > tmp-generated.c
> >        if diff tmp-generated.c $@ >/dev/null 2>&1; then \
> >          rm -f tmp-generated.c; \
> >        else \
> >          mv -f tmp-generated.c $@; \
> >        fi
> >
> > lookup_SOURCES = lookup.c $(srcdir)/generated.c
> I've got it living in $(srcdir) now, thanks.  I can't see why your
> version of a lazy update would speed it up though.  It still runs
> ./generate, and now it's running diff too, right?

The version Ralf provided always runs generate but it only updates
generated.c (and thereby its timestamp) when the output has changed.
This means that Make no longer thinks that it needs to recompile
everything that depends on generated.c (lookup in the example above).
An example might be if you were to fix the indentation or add a comment
to generated.c (or changed anything else that doesn't effect the output)

Although I must admit I'm not sure what he means by 
> > [...] this shouldn't matter for read-only trees iff your
> > dependencies are set up correctly [...]
I'm not really sure how else you could have generated.c on the source
tree and not break dist-check, but then I'm probably missing something

Also, I don't want to split hairs here but isn't it less portable to use
$@ in a non-suffix rule?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]