<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi CMakers!<br>
    <br>
    I would like to discuss absolute path printing of CMakeLists.txt
    file in title of CMake error messages (see
    cmListFileBacktrace::PrintTitle ).<br>
    ( code for discussion:
<a class="moz-txt-link-freetext" href="https://gitlab.kitware.com/vbspam/cmake/commit/ab3f992e9f39b81859d5ab3fa17eba25cfc61136">https://gitlab.kitware.com/vbspam/cmake/commit/ab3f992e9f39b81859d5ab3fa17eba25cfc61136</a>
    )<br>
    <br>
    <b>What is the issue?</b><br>
    <br>
    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:<br>
    <br>
    ```code<br>
    <pre>CMake Error at libraries/LibFoo/tests/CMakeLists.txt:16 (set_property):</pre>
    <pre>  set_property could not find TARGET LibFoo.  Perhaps it has not yet been</pre>
    <pre>  created.</pre>
    <pre>Call Stack (most recent call first):</pre>
    <pre> libraries/LibFoo/tests/CMakeLists.txt:36 (add_simple_test)</pre>
    ```<br>
    <br>
    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. <br>
    This could happen even by wrong design of 'some automated tool' or
    by parallel CMake execution using the same cout/cerr.<br>
    <br>
    Instead it would be nice if there will be an option to print the
    file name as absolute path. Please see desired example:<br>
    <br>
    <br>
    ```code<br>
    <pre>CMake Error at <font color="#ff0000">/home/user/Projects/</font>libraries/LibFoo/tests/CMakeLists.txt:16 (set_property):</pre>
    <pre>  set_property could not find TARGET LibFoo.  Perhaps it has not yet been</pre>
    <pre>  created.</pre>
    <pre>Call Stack (most recent call first):</pre>
    <pre> libraries/LibFoo/tests/CMakeLists.txt:36 (add_simple_test)</pre>
    ```<br>
    <br>
    <b>What is the real driver behind?</b><br>
    <br>
    - 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.<br>
    <br>
    - 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).<br>
    <br>
    <b>Why I bother you with this issue?<br>
      <br>
    </b>Even though I did my own fixture for myself, I believe that this
    issue may influence also other users <br>
    (e.g. <br>
    - <a class="moz-txt-link-freetext" href="https://cmake.org/pipermail/cmake/2014-March/057164.html">https://cmake.org/pipermail/cmake/2014-March/057164.html</a><br>
    - or the author of the conditional relative printing itself - please
    see '<span id="LC398" class="line"><span class="n">GetIsInTryCompile</span><span
        class="p"></span></span>()'' flag<br>
    )<br>
    <br>
    Last but not least: it is not much practical to maintain my own
    CMake repo just for this change :-).<br>
    <br>
    <b>What next?<br>
      <br>
    </b>I would like to know if someone is interested and would accept
    this as an issue.<br>
    I can then fill this as an issue and in other discussion propose how
    to design the absolute/relative path switching.<br>
    At this moment the '<span id="LC398" class="line"><span class="o"></span><span
        class="n">GetIsInTryCompile</span><span class="p"></span></span>()'
    flag which influence the absolute/relative printing is set only as
    hardcodded value (as far as I know).<br>
    <br>
    Looking forward for constructive discussion!<br>
    <br>
    Best regards<br>
    Venca<br>
    <br>
    <br>
  </body>
</html>