Bug 132074

Summary:	make install should use stat to check for changed files
Product:	[Developer tools] buildsystem	Reporter:	Alexander Neundorf <neundorf>
Component:	KDE4 (cmake)	Assignee:	Alexander Neundorf <neundorf>
Status:	RESOLVED FIXED
Severity:	normal	CC:	zander
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Alexander Neundorf 2006-08-08 19:36:24 UTC

Version:            (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc 
OS:                Linux

make install should not install files that have not changed. doing a make install in a reasonably sized subproject will copy and install all files and libraries regardless of the amount of changed files there are.  This means that altering one source file and doing an install will take a lot longer then needed. Altering rc files will trigger a buildsycoca and installing libraries takes very long as well.  In other words, cmake takes too long by doing unneeded work

Comment 1 Alexander Neundorf 2006-08-08 19:39:11 UTC

I think this is not the case.
Older cmake versions did do that (< 2.4.1).
With recent versions it looks as if everythings gets installed (the message is printed for every file), but only the files which have changed actually get installed.

Doesn't this work for you ?

You can set the environment variable CMAKE_INSTALL_ALWAYS to TRUE to force that always everything gets installed.

Alex

Comment 2 Thomas Zander 2006-08-08 20:27:30 UTC

Maybe I didn't specify the problem clearly enough.
The basic problem is that typing make install/fast twice will make the second time take an awful long time for a process thats not moving any bytes.

To debug this; can you tell me how cmake knows that nothing actually changed? Does it do a diff or otherwise read the files?

I expect a make install to do something along these lines:

#for file x that is installed in location y
if y is missing
  copy x to y
else if stat(y) shows that the installed file is
  - a different filesize
  - an older date
  then copy x to y

The current algorithm seems to have some problems.  Maybe you can rename (and reopen) this bugreport with the right title based on this extra info.

Comment 3 Alexander Neundorf 2006-08-08 21:47:22 UTC

AFAIK it compares the file contents.

Alex

Comment 4 Thomas Zander 2006-08-08 22:02:23 UTC

Changed title to specify real bug.

Comment 5 Alexander Neundorf 2006-08-08 22:28:13 UTC

Does it help if you "make install" in koffice/libs/ ?

What do you think about having a lib/ or libs/ toplevel subdir in every KDE module which _can_ be compiled and installed independent from the rest of the module ?

Comment 6 Thomas Zander 2006-08-09 12:40:08 UTC

On Tuesday 8 August 2006 22:28, Alexander Neundorf wrote:
> Does it help if you "make install" in koffice/libs/ ?


No. There are other usecases where this would fail.

For example when in krita you change something in the core library a make 
install would first compile + link all plugins (that link against the 
core) and only then start the install.
So, your suggestion is just attacking 1 problem.

I suggest you look at how unsermake did install things to see what 
behavior I expect from its replacement.

Comment 7 Elvis Stansvik 2006-08-09 12:56:54 UTC

I second Thomas' expectation that file meta data such as timestamps and sizes should be used, instead of a full diff.

Comment 8 Thomas Zander 2006-08-10 15:05:53 UTC

From version 0.8 the unsercmake command I wrote has the requested behavior. Would be nice if this can go into cmake proper in a next version.
For now:  http://members.home.nl/zander/unsercmake

Comment 9 Alexander Neundorf 2006-08-29 21:12:57 UTC

This has now an entry in the cmake bug tracker: http://www.cmake.org/Bug/bug.php?op=show&bugid=2691 , so I close it here. Please follow the issue over at the cmake bug tracker.