Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc OS: Linux Whenever typing 'make' cmake will do dependency checking over the whole of the project. This has the effect that adding api docs in kdecore and typing make in kdeui will trigger a compile in kdecore. This is unwanted. The solution cmake provides is to turn off all dependency checking, which is even worse since we invented dependency checking for a reason. The wanted behavior would be for cmake do dependency checking based on the directory its invoked in. Invoking it in kdeui will check for dependencies in that dir and all subdirs, but never outside of that subproject
That this behaviour is "unwanted" is your personal opinion. If it wouldn't be that way, other people would complain "I want to build kdeui, but it doesn't notice that I edited kdecore and still links to an obsolete version of it !". So the current behaviour is at least more correct than if it wouldn't do the checking, but it is different to the behaviour you get with autotools, and that's what most UNIX/Linux developers are used to. Our modules in KDE svn are really big. So it really takes some time to do the scanning and it would be nice if it was faster. But doesn't "make kdeui/fast" (since cmake 2.4.3) do what you want ?
> That this behaviour is "unwanted" is your personal opinion. Actually; the opinion that the new behavior is limited to just the cmake maintainers and yourself as many emails on k-c-d and talks on IRC stated. I suggest you stop being lead by your personal opinions and look at the problems people have.
k-c-d + irc != all_cmake_users - cmake_devs - me As for stopping not to look at the problems people have: since january I'm spending basically every free minute on the KDE buildsystem. When people report problems or issues I have to set priorities. Things which work but could be improved have low priority compared to other issues. I have to look for ways how to make things work with as little work for me as possible (e.g. by trying some special options etc.) I cannot and will not implement each and every wish of every single KDE developer. And you know, not every KDE developer has the same wishes. As you can see above, I agreed that the checking takes some time and that it would be better if it would take less time. Alex
> But doesn't "make kdeui/fast" (since cmake 2.4.3) do what you want ? Just for the record (since I answered this question many times, each time with the exact same answer, and you just keep asking anyway) The wanted behavior is to not change behavior from how automake, unsermake etc do things and that is to respect the directory I cd-ed into and from then on see the current dir as a boundary that cmake should stay inside of. This means that any changes outside that dir should be ignored. So; alter kdecore/kapplication.h (add some docs or whatever) cd into kdeui make install I expect that 1) files that include the kapplication.h in kdeui still get recompiled, but 2) files in kdecore should not be recompiled. with the proposed /fast point 1 is not handled cd into kdeui alter utils/kcommand.cpp make install should recompile kcommand with your /fast this will not happen. I wrote a wrapper script that does mostly do this already by doing the dependency checking itself and using the no-dependencies switch /fast. See: http://members.home.nl/zander/unsercmake
I agree that /fast sometimes does too little dependency checking, so that sometimes you have to resort to deleting object files to force it to recompile things which need to be recompiled in the subdirectory you're in. But /fast is a very useful feature when you know what needs to be rebuilt. I also like the fact that cmake has the ability to do much more thorough dependency checking than autotools (i.e. when used without /fast). But we really need an intermediate speed option as well, to do what Thomas asks for. Perhaps that should be the default, and the current default (i.e. check everything exhaustively) should be available through a /slow (or a more diplomatically named /thorough ?) option.
FYI, I've opened a CMake bug for this: http://www.cmake.org/Bug/bug.php?op=show&bugid=3658 I've been planning to fix this for a while but I'm not sure when I'll get to it. The CMake <= 2.0 Makefile generator did support running make from a subdirectory and not building globally. The policy is that running make from the top always works and running make from a subdirectory is more local but not guaranteed to produce an exactly up-to-date build using all dependencies.
This has now a bug entry in the cmake bug tracker (http://www.cmake.org/Bug/bug.php?op=show&bugid=3658), so I close it here. Please follow the issue over at the cmake bug tracker.