Review Request: Fix MakeOutput items for cmake builds with relative paths

[Manuel Massing]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100745/
-----------------------------------------------------------

(Updated Feb. 27, 2011, 4:03 p.m.)


Review request for KDevelop.


Changes
-------

Thanks David for the review. Updated the patch for fine-grained (i.e, per-file) MRU semantics for currentDirs
search order.

I've checked and cmake parallel builds definitely interleave build directories, i.e.
subdirectories are not guaranteed to be processed in sequential order. This means it's
unfortunately not sufficient to check currentDirs.back().

While I think the last patch already matched the behaviour of the makefile case with
respect to search path order,you are right that updating the most recent build dirs
with higher (per-file instead of per-directory) granularity will reduce the probability of
associating an error with the incorrect source file (in any case, only a problem for parallel builds).

While it's still not completely watertight, mismatching a file can only occur
under very specific circumstances - I think the following must hold for a mismatch to occur:

1) Parallel builds
2) The build must take place in the source tree (otherwise the relative paths are unambiguous)
   - but in out-of-source build this could still affect e.g. auto-generated moc cpp files
3) At least two source files need to share the same name
4) The source files must reside in different source directories, but share a common sub-path, e.g.

		/src/commonSubPath/test.cpp
		/src/somePrefix/commonSubPath/test.cpp

5) Additionally, if currentDirs are held in per-file most-recently-used order, the source files must also be compiled directly
   one after the other

In such a case, currentDirs would contain:

	$buildDir/commsubSubPath
	$buildDir/somePrefix/commonSubPath

If a build error occurs in commonSubPath/test.cpp, gcc gives us the relative filename as "test.cpp".

Doing a most recently used match will then find the file $buildDir/somePrefix/commonSubPath/test.cpp
before the real culprit, $buildDir/commonSubPath/test.cpp

Anyway looks like a total edge-case to me. But I've been able to carefully hand-craft a cmake project where
it fails :-) Other than that, I doubt this case is hit in practice.


Summary
-------

Fixes MakeOutput items for cmake builds which use relative paths 
(i.e. cmake projects with CMAKE_USE_RELATIVE_PATHS set to on).

Previously, errors generated by source files with relativ paths
were not clickable because MakeOutputModel does not know about
the directories they are built in.

Because cmake is not verbose enough to indicate directory changes,
observes where object files are being built and use these paths
as search path for urlToFile.


Diffs (updated)
-----

  projectbuilders/makebuilder/makeoutputmodel.h 5ac45535a0d6d5496c48631d281e322c7b1b792e 
  projectbuilders/makebuilder/makeoutputmodel.cpp 09bb72e4621e8033666d6c0c36c1fc34834754a9 
  projectbuilders/makebuilder/outputfilters.cpp 3b6b806d73375daf85831f734153a5bf4e2293d6 

Diff: http://git.reviewboard.kde.org/r/100745/diff


Testing
-------

Tested on cmake project with SET(CMAKE_USE_RELATIVE_PATHS ON).


Thanks,

Manuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110227/1320f01c/attachment.html>