1. 19 Jan, 2015 1 commit
  2. 29 Dec, 2014 1 commit
  3. 14 Sep, 2014 2 commits
  4. 13 Sep, 2014 1 commit
  5. 05 Aug, 2014 2 commits
  6. 29 Jul, 2014 1 commit
  7. 10 Jul, 2014 1 commit
  8. 09 Jul, 2014 1 commit
  9. 19 Dec, 2013 2 commits
    • Milian Wolff's avatar
      Refactor IncludePath{Computer,Resolver} interaction. · 686a5418
      Milian Wolff authored
      We now still call the resolver's includeResolver.resolveIncludePath
      as that is required to support custom include paths in the hidden
      .kdev_include_paths files.
      Instead, we disable the make-resolution when we get any paths from
      the build manager.
      Also get rid of the code which tries to be faster by looking at
      the DUChain to find include paths. It's not faster. Also note how
      the IncludePathResolver has a cache internally.
    • Milian Wolff's avatar
      Cleanup code · ce518182
      Milian Wolff authored
  10. 02 Dec, 2013 1 commit
    • Milian Wolff's avatar
      Port IncludePathComputer away from deprecated Url API. · eb5b2877
      Milian Wolff authored
      Instead of introducing Path here though, we simply operate on QStrings
      directly as is done already in lots of other places. This simplifies
      the code and is fine here as we are just looking for local string
      paths anyways. The additional API or memory savings of Path are not
      important here, considering that the list of include paths is small
      and temporary anyways. The overhead of converting to Path first would
      not be worth it here.
      With this patch in place, no Path conversions to KUrl take
      place anymore when running KDevelop and parsing code.
  11. 07 Nov, 2013 1 commit
  12. 19 Jul, 2013 1 commit
  13. 31 May, 2013 1 commit
    • Alexandre Courbot's avatar
      Preserve relative paths in unresolved include assistant · bb3dcf33
      Alexandre Courbot authored
      The unresolved include assistant include relative paths which are
      resolved from the storage directory. However, when reopening the
      assistant, all relative paths would be turned into absolute ones. Fix
      this by converting relative paths in a dedicated method of
      CustomIncludePathsSettings and use this one in places where absolute
      paths are desirable, leaving the assistant with the original relative
      paths for editing.
      REVIEW: 110295
  14. 24 Apr, 2010 1 commit
  15. 07 Apr, 2010 1 commit
  16. 05 Apr, 2010 1 commit
  17. 15 May, 2009 1 commit
    • David Nolden's avatar
      Manage a ModificationRevisionSet that marks the file-version dependencies of include-paths. · ba9dcfc9
      David Nolden authored
      If there is a custom include paths file, add it to that set, so the include-paths are re-computed when that file is changed.
      Also make the include-path resolver cache depend on that file, and also add the Makefile to that set, so the include-paths are recomputed when the makefile has changed.
      Generally try better to detect when old include-paths can be re-used, and when they need to be re-computed.
      Mark the top-context as "needs update" when its include-path dependency needs one.
  18. 13 Apr, 2009 2 commits
    • David Nolden's avatar
      Add a new assistant, that allows conveniently taking actions when included files were not found: · f8829c70
      David Nolden authored
      - Propose the "Open project for current file" action
      - Add a full convenient management user-interface for the custom include-paths, and custom build-dir mappings in the ".kdev_include_paths" helper files.
    • David Nolden's avatar
      Allow setting a relative out-of-source build location, using the same... · 10df2cda
      David Nolden authored
      Allow setting a relative out-of-source build location, using the same mechanism as custom include-paths, exclusively for the include-path resolver. This allows making code-completion work without having to load a project, or as a
      workaround until the custom-makefile support allows out-of-source builds.
      Syntax example for a mapping:
      If the file /home/nolden/kdedev/.kdev_include_paths contains this line:
      RESOLVE: SOURCE=/home/nolden/kdedev BUILD=/home/nolden/kdedev/build-mini
      Then code-completion, use-building, etc. will instantly work correctly for all projects that have their directory within /home/nolden/kdedev,
      and their build-directory equally named and with the same directory structure within /home/nolden/kdedev/build-mini, no matter whether they have a project loaded.
      Of course, only under the assumption that the Makefiles are structured in such a way, that the include-path resolver works. This is usually at least the case for cmake, unsermake, and simple custom written files.
  19. 06 Mar, 2009 1 commit
  20. 15 Feb, 2009 1 commit
  21. 18 Dec, 2008 1 commit
    • David Nolden's avatar
      - Split up the findIncludePaths functionality into the part that needs to be... · 0232d6f1
      David Nolden authored
      - Split up the findIncludePaths functionality into the part that needs to be executed in the foreground thread and the part that involves executing make, which blocks the UI and can also be executed in the background thread.
      Now the blocking part is executed in the background-thread when the request comes from a parse-job, which should lead to significantly less UI lockups during full project parsing.
  22. 25 Nov, 2008 1 commit
  23. 16 Apr, 2008 1 commit
  24. 27 Sep, 2007 1 commit
  25. 16 Aug, 2007 1 commit
  26. 25 Jul, 2007 1 commit
  27. 24 Jun, 2007 2 commits