Version: kdevelop-9999, kdevplatform-9999, probably both svn r1077446 (using KDE 4.3.3) Compiler: x86_64-pc-linux-gnu-gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5) OS: Linux Installed from: Gentoo Packages Sometimes when I run make, some source files don't get built. I think the cause is file mtimes somehow getting dated from before the file was last modified. I switch branches in git a lot (causing files to also be modified outside kdevelop). I run make both by pressing F8 inside kdevelop, and by running make from the konsole. I often make test changes, save, compile, undo the changes, save again, compile again. I don't know how to reproduce. Adding a script to the makefile to check if the contents of the file have changed since the last make, and to touch the source file mtime if it has, didn't help. Somehow the source files ended up getting mtimes minutes earlier than when the file was last built. If it's not kdevelop either setting the mtime of files to the past, or saving files without updating the mtimes, then I'm confused and in that case, sorry for the report. Any case where any editor changes the contents of a file (or undoes a change) without updating the mtime to the present time will cause some files not to be built with make which should have been, since the editor has no way of verifying that make was not run at some point in time after the file's new mtime.
sounds like c++ support's includepath resolver. We've noticed the opposite already in kdevelop ourselves, but couldn't pin-point it. There sometimes make builds "too much" after working with the project for a bit.
Now I got a source file, which I know for sure I just modified a minute ago, with a timestamp almost 6 hours earlier. So it's no longer just an impression that files are somehow getting backdated.
Now for something a bit more specific. My Makefile now does ls -l of the source and object files, sleeps 0.5 seconds, and does another ls -l of the source and object files. I press F8 to build, which runs make. (I don't remember whether I saved in advance this particular time, or if it autosaved when pressing F8.) ls -l says that the object file is a few minutes old, and the source file is new. 0.5 seconds pass, doing nothing. ls -l says now that the source file is now a few minutes old - more specifically, a couple of seconds older than the object file. So kdevelop seems to be somehow recycling an old timestamp on the source file, even after having saved it with the correct timestamp. I'm pretty sure that no editor should ever be changing timestamps in any way other than by writing a file to disk, for any reason.
Sorry, forgot to comment that a different time I pressed F8, the timestamp of the file went 1 second forwards in time, during the make process sleep, so it is happening in both directions.
I am experiencing same bug.Whenever i modify a source file kdevelop doesnt update the modification time,the problem only occurs when the background parser is running,if i save after parsing is finished the time will be set properly,this causes make to skip changed files. By background parser i mean the one which starts immediately after i typed some changes to the source. Kdevelop also seems to change modification time unnecessarily during parsing at startup. compiled kdevelop 4 from svn,revision 1093125.
I'm experiencing this also. I have found that modifying (and saving) the file twice somehow fixes the issue.
*** Bug 232232 has been marked as a duplicate of this bug. ***
I have the gut feeling that the -W switch passed to make in the include path resolver is the cause for this: -W file, --what-if=file, --new-file=file, --assume-new=file Pretend that the target file has just been modified. When used with the -n flag, this shows you what would happen if you were to modify that file. Without -n, it is almost the same as running a touch command on the given file before running make, except that the modification time is changed only in the imagination of make. Yes, we pass -n, hence we "touch" quite a lot of files... Which could lead to all kinds of havoc... Not least among them that the DUChain cache probably doesn't work for custom make file projects (where the include path resolver is used). Since every file gets touched, it's considered new and will get parsed :-S
Actually make shouldn't touch anything, but it's the IncludePathResolver itself, look at e.g.: http://pastebin.com/bN2E8vxa (the touch messages)
It's probably safe to assume that if this is happening, it's because of the FileModificationTimeWrapper in includepathresolver.cpp. This class sets the file modification time ahead of calling make/unsermake, and then resets it. If there is an easy way to reproduce a dating error, this could be resolved. On the other hand, WTF? It looks like it's a special hack to support the unmaintained since 2007 unsermake, which apparently doesn't have a -W switch like make. By default this shouldn't be used if make is being used, but there is an option to enable it for make too (not sure if it gets set). Can someone who knows say if we still need this fearsome hack?
This might also be required for other build-systems, for example cmake, because the "make" calls of cmake only delegate the work to other calls, and doesn't propagate "force changed" flag. Maybe it's time to start trusting the cmake support a bit more and making the include-path resolver optional there. However we'll keep needing a similar hack for other "make" based build-systems, so it would also be nice if we could improve this hack to never fail. Btw. some of you are misunderstanding this quite a bit, so here is what the include-path resolver does: If it tries to resolve the include-paths of file a.cpp (in psuedo code): 1. newtime = NOW 2. oldtime = modtime( a.cpp ) 3. modtime( a.cpp ) = newtime 4. Call "make -n" to get the gcc command 5. if( modtime( a.cpp ) == newtime ) 5.1 then modtime( a.cpp ) = oldtime And there are two tiny windows where this can cause problems: * If the file is changed between 2 and 3 or 5 and 5.1, then the change will be ignored, because the modification-time will be reset to the old one * If another "make" is called by the build-system between 3 and 5, then this file will be rebuilt needlessly
I believe this is the same issue that is reported in the RH Bugzilla on https://bugzilla.redhat.com/show_bug.cgi?id=784845 for Fedora 15 and kdevelop-4.2.3
So in 2016, the mtime changing apparently still causes issues. We just had a user in #kdevelop reporting that with KDevelop he constantly needs to rebuild unchanged code when hacking on the Linux Kernel. This is the only place in KDevelop that could cause this afaics. @David: Could this mtime changing code be removed? Any chance you'd be willing to work on that, after all the years? :) I don't have a single clue about this part of KDevelop and I'd love to have someone change it who fully understands what's happening...
*** Bug 376432 has been marked as a duplicate of this bug. ***
commit 4f3813672089258a2044cbeb901c9432dc8d9a03 Author: Jan Ziak <0xe2.0x9a.0x9b@gmail.com> Date: Mon Feb 20 21:52:07 2017 +0100 Avoid utimes() in custommake projects, remove unsermake support Reviewed By: mwolff Differential Revision: https://phabricator.kde.org/D4612 BUG: 376432