1. 29 Sep, 2017 13 commits
  2. 28 Sep, 2017 9 commits
  3. 25 Sep, 2017 3 commits
    • Friedrich W. H. Kossebau's avatar
      5dbd2b27
    • René J.V. Bertin's avatar
      Document how to determine which optional dependencies are used (e.g. QtWebKit... · 69548771
      René J.V. Bertin authored
      Document how to determine which optional dependencies are used (e.g. QtWebKit instead of QtWebEngine
      
      Summary:
      As long as QtWebKit remains a supported option for documentation rendering users might want an option to build KDevelop against that library even if QWE is present on their system.
      
      KDevelop uses enough resources of its own, so an option to avoid using the additional resource-hungry QWE is very welcome (after all, many will probably already have a chrome-based browser running).
      
      This patch is the simplest possible implementation, and doesn't advertise itself by creating an option variable in the toplevel CMake file. I'd be happy to add that possibility though.
      
      Test Plan: It would be nice if CMake's summary printed a list of optional dependencies that were disabled explicitly.
      
      Reviewers: #kdevelop, apol, kfunk
      
      Reviewed By: #kdevelop, kfunk
      
      Subscribers: kfunk, apol, kdevelop-devel
      
      Tags: #kdevelop
      
      Differential Revision: https://phabricator.kde.org/D7950
      69548771
    • Script Kiddy's avatar
      SVN_SILENT made messages (.desktop file) - always resolve ours · c68892a5
      Script Kiddy authored
      In case of conflict in i18n, keep the version of the branch "ours"
      To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
      c68892a5
  4. 24 Sep, 2017 3 commits
  5. 23 Sep, 2017 2 commits
  6. 21 Sep, 2017 4 commits
    • Francis Herne's avatar
      Remove extra parens · ac0ef9f3
      Francis Herne authored
      Fixes compilation after f149bed1
      ac0ef9f3
    • Milian Wolff's avatar
      Workaround parse errors due to missing implementation of __has_include · f149bed1
      Milian Wolff authored
      GCC reports the following two defines as built-in:
      
      There are no definitions of __has_include{,_next}__ available in clang
      though, leading to parse errors like:
      
      2 problems encountered:
       "Function-like macro '__has_include__' is not defined" "" [ (1, 12)  ->  (1, 25) ]
       "Broken c++11 setup (__has_include)" "" [ (4, 9)  ->  (4, 14) ]
      
      This then propagates to all kinds of issues, most notably when parsing
      Qt headers. There, we suddenly fail to realize that the compiler is
      C++11 capable (__has_include(<atomic>) errors out), and more.
      
      Overall, the language parser is suddenly completely broken. We now
      catch these two function macros and skip them, to ensure they never
      override the builtin functionality of clang. This fixes the new unit
      test and also makes KDevelop behave properly again with newer Clang
      when parsing Qt 5 code bases.
      
      The question now is: Why do we use GCC by default to find the built-in
      defines? I thought we'd default to Clang since a long time by now...
      
      (cherry picked from commit ea3cb5a8)
      f149bed1
    • Milian Wolff's avatar
      Dump defines file when KDEV_CLANG_DISPLAY_DEFINES is set · 3516c318
      Milian Wolff authored
      We need to jump through some hoops here, since it's not easy
      to rewind the temporary file itself to have it output its contents.
      So instead, close the file and reopen it separate to read the
      contents.
      
      (cherry picked from commit bbc57107)
      3516c318
    • Milian Wolff's avatar
      Prefer the first available compiler as default compiler · 5d75d8d6
      Milian Wolff authored
      Commit 65106bec introduced this regression: The code used to
      return early when a compiler was found. The new loop to cache
      the result always iterates over all compilers.
      
      Essentially, this reverts the whole logic within the IDM: Instead
      of prefering, say, Clang over GCC, it actually does the opposite
      and will prefer GCC over Clang. This patch adds the missing break
      to restore the old behavior.
      
      This ensures we will once again use Clang instead of GCC by default
      for includes and built-in defines. As exemplified by the recent
      breakage (__has_include) when using GCC, and the history of the
      shaky GCC integration, this is important for a good default
      impression of KDevelop.
      
      (cherry picked from commit f6e3d8b9)
      5d75d8d6
  7. 20 Sep, 2017 5 commits
  8. 19 Sep, 2017 1 commit