1. 22 Feb, 2017 1 commit
  2. 15 Feb, 2017 3 commits
  3. 14 Feb, 2017 3 commits
  4. 10 Feb, 2017 1 commit
  5. 09 Feb, 2017 1 commit
  6. 08 Feb, 2017 1 commit
  7. 03 Feb, 2017 3 commits
  8. 30 Jan, 2017 2 commits
  9. 27 Jan, 2017 1 commit
  10. 26 Jan, 2017 3 commits
  11. 25 Jan, 2017 1 commit
    • hjk's avatar
      ProjectExplorer: Make the FlatModel a Utils::TreeModel · 3c743346
      hjk authored
      The FlatModel is essentially a proxy model keeping expansion and
      filter state per ProjectTree(View). Using a Utils::TreeModel makes
      it fast enough to allow recreation of the proxy structure on
      structural changes simplifying the parent/child logic significantly.
      The {Session,Project,Folder,File}Node hierarchy still is still primary
      information and shared by all views.
      Change-Id: Ic08180a19bda37908280ff30e0737d188ed93e92
      Reviewed-by: default avatarRobert Loehning <robert.loehning@qt.io>
      Reviewed-by: Tobias Hunger's avatarTobias Hunger <tobias.hunger@qt.io>
  12. 10 Jan, 2017 1 commit
    • Tobias Hunger's avatar
      qmake: fix missing OTHER_FILES in project tree · 624339ea
      Tobias Hunger authored
      ... in subdirs projects which actually have any subdirs.
      that would happen via this mechanism in QmakeProFileNode::evaluate():
      first, IncludedPriFile nodes with proFile = null are created for the
      subdirs. subsequently, this tree is enriched by transforming the
      reader's included files. that loop iterates over all already created
      nodes and tries to match them against included files. at nesting level
      one, this would now run into the nodes created for the subdirs. the code
      failed to skip over these nodes, and would thus create a bogus node for
      the .pro file (as it has the parent null in the mapping of included
      files). this node would not be included into the tree due to the loop
      prevention in QmakeProFileNode::applyEvaluate() (it obviously had the
      same file path as its parent), but at the same time it would catch the
      files meant for the root node due to defeating the fallback in
      Task-number: QTCREATORBUG-17473
      Change-Id: Ice9f667345148be42297cc21ff0a73058f27cc38
      Reviewed-by: Tobias Hunger's avatarTobias Hunger <tobias.hunger@qt.io>
  13. 05 Dec, 2016 3 commits
  14. 14 Nov, 2016 2 commits
  15. 10 Nov, 2016 3 commits
  16. 09 Nov, 2016 1 commit
  17. 03 Nov, 2016 3 commits
  18. 02 Nov, 2016 1 commit
  19. 01 Nov, 2016 6 commits
    • Oswald Buddenhagen's avatar
      de-duplicate INSTALLS resolution · 5f17c280
      Oswald Buddenhagen authored
      don't resolve the source files once for deployment and once for the
      project tree.
      Change-Id: Ifddf8fc7883bf025d3640de0d6676b5930991088
      Reviewed-by: Tobias Hunger's avatarTobias Hunger <tobias.hunger@qt.io>
    • Oswald Buddenhagen's avatar
      remove duplicate resolution of sources from cumulative pass · 4a59a7d7
      Oswald Buddenhagen authored
      instead of resolving all sources both in the exact and the cumulative
      pass and de-duplicating the joined list in the end, resolve only these
      files from the cumulative pass which are unique to it to start with.
      Change-Id: Ie3327799ecd94f8710f8b99bcc46998790ba2c74
      Reviewed-by: Tobias Hunger's avatarTobias Hunger <tobias.hunger@qt.io>
    • Oswald Buddenhagen's avatar
      de-duplicate resolution of exact sources · e19fa276
      Oswald Buddenhagen authored
      rather than resolving them once in bulk (for the code model) and once
      per pri file (for the project view), resolve them only in bulk, but
      "tag" them. then do a cheap filtering pass for the project view.
      as a side effect, this fixes the problem that sources that are listed by
      a file that is not shown in the project tree (as is the case for qrc
      files synthesized by resources.prf) would not be shown at all. instead,
      these sources now appear belonging directly to the pro file.
      Task-number: QTCREATORBUG-3670
      Change-Id: I1a1756d95bd90db4da1274eebcc4dad2a854f43d
      Reviewed-by: Tobias Hunger's avatarTobias Hunger <tobias.hunger@qt.io>
    • Oswald Buddenhagen's avatar
      apply a build pass to retrieve all project variables · 0afcbaa9
      Oswald Buddenhagen authored
      so far, we used a build pass only to retrieve accurate target
      information from the exact evaluator. however, this is insufficient for
      at least two reasons:
      - the recently introduced postprocessing of RESOURCES in resources.prf
        is executed only during build passes
      - some relevant variables are build pass specific, for example
        INCLUDEPATH when it includes RCC_DIR
      an additional upside is that using the build pass' values is consistent
      with qmake's vcxproj generation mode.
      on the downside, the extra cumulative build pass adds 33% of pure
      project evaluation time. however, this isn't as bad, as the pro files
      are already loaded and parsed, and the expensive source file resolution
      moves completely to the build pass.
      the alternative of defeating the build pass logic (as lupdate does) is
      not feasible, as we rely on accurate target information from an actual
      build pass for the run configurations.
      note that this all applies only to windows (and macos when explicitly
      configured with -debug-and-release).
      Task-number: QTCREATORBUG-16019
      Change-Id: I8a97856b3b738aa1a581d24ba24bb3e7199d8078
      Reviewed-by: Tobias Hunger's avatarTobias Hunger <tobias.hunger@qt.io>
    • Oswald Buddenhagen's avatar
      unify {,obj}c++{source,header} handling in qmake project manager · 7e86b988
      Oswald Buddenhagen authored
      consistently with Xcode, qmake nowadays knows only one SOURCES list,
      which is automatically classified by extension.
      to replicate that, we actually copy the objective_c.prf file from qt
      5.6.3 and use it to override whatever comes with qt, so we can treat all
      qt versions uniformly.
      also, the code model throws away the information which files were listed
      as sources and which as headers. this is technically incorrect, as a
      source may be only included rather than compiled, but there is no point
      in extracting information which is not used.
      conclusion: lump all c-like sources into one variable as far as project
      processing is concerned.
      and as far as configuration goes, our code model doesn't differentiate
      anyway, so the duplicated setup paths can be eliminated as well.
      Change-Id: I24b1bc056f8d9eb579c9378817f602912ab49971
      Reviewed-by: Tobias Hunger's avatarTobias Hunger <tobias.hunger@qt.io>
    • Oswald Buddenhagen's avatar
      remove some pointless complexity relating to IncludedPriFile · 4148b05e
      Oswald Buddenhagen authored
      each such object has exactly one associated ProFile if it shall result
      in a pri node, and no ProFile if it shall result in a pro node. there is
      no point in dealing with lists at various levels.
      Change-Id: I930fd8c14fcd6336cd297bacefdd0036f556741b
      Reviewed-by: Tobias Hunger's avatarTobias Hunger <tobias.hunger@qt.io>