[CMake] Absolute path printing of CMakeLists.txt files in title of CMake error messages.

[vbspam]

Hi CMakers!

I would like to discuss absolute path printing of CMakeLists.txt file in
title of CMake error messages (see cmListFileBacktrace::PrintTitle ).
( code for discussion:
https://gitlab.kitware.com/vbspam/cmake/commit/ab3f992e9f39b81859d5ab3fa17eba25cfc61136
)

*What is the issue?*

When there is a problem in CMakeLists.txt, CMake reports the file the
problem occurs in as relative to its CMAKE_BINARY_DIR. Please see example:

```code

CMake Error at libraries/LibFoo/tests/CMakeLists.txt:16 (set_property):

  set_property could not find TARGET LibFoo.  Perhaps it has not yet been

  created.

Call Stack (most recent call first):

 libraries/LibFoo/tests/CMakeLists.txt:36 (add_simple_test)

```

The issue is that when some automated tools do not know the
CMAKE_SOURCE_DIR, then they have hard time to determine which file is
referred to.
This could happen even by wrong design of 'some automated tool' or by
parallel CMake execution using the same cout/cerr.

Instead it would be nice if there will be an option to print the file
name as absolute path. Please see desired example:


```code

CMake Error at /home/user/Projects/libraries/LibFoo/tests/CMakeLists.txt:16 (set_property):

  set_property could not find TARGET LibFoo.  Perhaps it has not yet been

  created.

Call Stack (most recent call first):

 libraries/LibFoo/tests/CMakeLists.txt:36 (add_simple_test)

```

*What is the real driver behind?*

- I use KDevelop as my Linux IDE which has as you may know pretty nice
CMake integration. The thing is, that when I use out-the-source build,
KDevelop has a problem when parsing the CMake error outputs. It assumes
the file is referred to the build directory (which in fact is correct
because the KDevelop runs the build command in the build directory), but
it is not. The CMake assumes the 'contract' is that the CMakeLists.txt
would be always considered as relative to the CMAKE_SOURCE_DIR.

- Another driver is when I do parallel build on build server, the actual
context of the CMake error line is hard to determine. Here is impossible
to get the proper context (the only relevant context is the printed line
itself).

*Why I bother you with this issue?

*Even though I did my own fixture for myself, I believe that this issue
may influence also other users
(e.g.
- https://cmake.org/pipermail/cmake/2014-March/057164.html
- or the author of the conditional relative printing itself - please see
'GetIsInTryCompile()'' flag
)

Last but not least: it is not much practical to maintain my own CMake
repo just for this change :-).

*What next?

*I would like to know if someone is interested and would accept this as
an issue.
I can then fill this as an issue and in other discussion propose how to
design the absolute/relative path switching.
At this moment the 'GetIsInTryCompile()' flag which influence the
absolute/relative printing is set only as hardcodded value (as far as I
know).

Looking forward for constructive discussion!

Best regards
Venca


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170212/968941e7/attachment.html>