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
