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
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
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.
AFAIK it compares the file contents. Alex
Changed title to specify real bug.
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 ?
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.
I second Thomas' expectation that file meta data such as timestamps and sizes should be used, instead of a full diff.
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
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.