Re: install without updating time stamps (was: Autoconf problem.)

[David Ronis]

Hi Ralph,

Thanks for the reply.  See below.


On Tue, 2008-08-19 at 22:50 +0200, Ralf Wildenhues wrote:
> Hello David,
> 
> * David Ronis wrote on Mon, Aug 18, 2008 at 03:26:26AM CEST:
> > I've just started following evo and friends in svn/trunk.   One thing
> > I've noticed is that small changes in one module will trigger almost
> > full rebuilds in the remaining ones (e.g., a small change in eds leads
> > to most of evo being rebuilt).    I'm doing this within a garnome build
> > tree,  and the usual way the build proceeds is to make install in each
> > directory (following the correct order of dependencies).
> 
> Thank you for the report.  There are two issues:
> 
> 1) It sounds like the way the build is done could possibly be improved.
> (I don't know the software, though, so I'll not look into this further
> unless there is interest.)

Perhaps I wasn't clear enough.  Say I have 2 projects,
evolution-data-server and evolution, where evolution depends on the
latter.  Running "make install" in e-d-s generates a large number of
libraries and .h files that evolution depends on (as do other components
of gnome).  Now running make in evolution works as expected; however,
after updating e-d-s via svn say, and making install, triggers a largely
full rebuild of evolution triggered by the dependencies on the e-d-s .h
files, even if none of them have changed.
 
> 2) install should be less eager to update time stamps.
> For this there is at least one step: recent install-sh from Automake
> supports -C which doesn't update the file at all (nor its time stamp)
> if the previously installed version didn't change.  This is a bit safer
> than GNU install's --preserve-timestamps (you could have manually
> changed the previously installed file, after building the new tree;
> this would lead to the newly installed file wrongly having an older
> time stamp than its prior).

Even better.  However, the evo folks seem to thing that autoconf should
do this automagically.  I know how to hack the generated makefiles to do
what I want (although I admit that the -C option is even neater)

> For full nice support of (2), probably a bit more should be done, but I
> guess as a workaround you can likely use
>   make install INSTALL='$(SHELL) $(top_srcdir)/build-aux/install-sh -C'


> with build-aux adjusted to whereever that file is.

See above.

> Note that the next Automake release will make this operation faster in
> many situations (with multi-file install).
> 
> Hope that helps.
> 
> Cheers,
> Ralf
> 

Thanks

David