1. 22 Feb, 2017 1 commit
  2. 15 Feb, 2017 3 commits
  3. 14 Feb, 2017 2 commits
  4. 03 Feb, 2017 1 commit
  5. 29 Nov, 2016 1 commit
  6. 09 Nov, 2016 1 commit
  7. 03 Nov, 2016 1 commit
  8. 02 Nov, 2016 1 commit
  9. 01 Nov, 2016 11 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>
      5f17c280
    • Oswald Buddenhagen's avatar
      don't use QList for items with sizeof(T) != sizeof(void*) · 09b4d9d5
      Oswald Buddenhagen authored
      Change-Id: Ibf6c494dff6700a269f1305c3bdaa4fad63cee98
      Reviewed-by: Tobias Hunger's avatarTobias Hunger <tobias.hunger@qt.io>
      09b4d9d5
    • 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>
      e19fa276
    • 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>
      0afcbaa9
    • 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>
      7e86b988
    • 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>
      4148b05e
    • Oswald Buddenhagen's avatar
      make VFS aware of exact vs. cumulative evaluation · a8010b0f
      Oswald Buddenhagen authored
      the cumulative evaluation has a good chance to make a mess of the
      virtual file contents created by the exact parsing, so better contain it
      to its own namespace.
      
      the ProFile cache also needs to keep the files separate. this
      specifically addresses the side issue discussed in QTCREATORBUG-10779.
      it also fixes attempts to deploy the wrong build when the variant is
      selected through a cache file, as in QTCREATORBUG-15815.
      
      in the project explorer, we don't track from which evaluation pass
      particular files came from, so we try the cumulative first to get the
      most contents, and fall back to the exact one if the former file is
      empty (or does not exist at all).
      
      Task-number: QTCREATORBUG-15815
      Change-Id: I2c1eb16c97526fa275a1c6a2eae9266d385859ac
      Reviewed-by: Tobias Hunger's avatarTobias Hunger <tobias.hunger@qt.io>
      a8010b0f
    • Oswald Buddenhagen's avatar
      chuck sysroot handling out of ProFileEvaluator · 1589ce3c
      Oswald Buddenhagen authored
      qmake doesn't do anything with sysroots at this level, so this code
      plain does not belong here.
      
      sysrootification is used when resolving INCLUDEPATH, which is emulating
      compiler behavior. this is done by higher-level code.
      
      Task-number: QTCREATORBUG-11944
      Change-Id: Ia25f0b6ef713e9809d974e3f3e49ba308b8c933f
      Reviewed-by: Tobias Hunger's avatarTobias Hunger <tobias.hunger@qt.io>
      1589ce3c
    • Oswald Buddenhagen's avatar
      introduce ProFileReader::fixifiedValues() · c42b12c9
      Oswald Buddenhagen authored
      ... and use it for PRECOMPILED_HEADER, INCLUDEPATH, and install target
      collection, instead of abusing ProFileReader::absoluteFileValues().
      
      specifically, this falls back to a location in the build directory when
      the path is relative and the file cannot be found. in qmake, this
      somewhat weird behavior ensures that chaining extra compilers actually
      works (and also ensures a lot of frustration with non-clean source dirs
      ...).
      
      this also fixes INSTALLS with .CONFIG no_check_exists.
      
      Task-number: QTCREATORBUG-14848
      Change-Id: Iaf9483c0c4586c464bd10a2aea7cbac7e0df1ec5
      Reviewed-by: Tobias Hunger's avatarTobias Hunger <tobias.hunger@qt.io>
      Reviewed-by: Christian Kandeler's avatarChristian Kandeler <christian.kandeler@qt.io>
      c42b12c9
    • Oswald Buddenhagen's avatar
      prune dead code surrounding isDeployable · fde9758f
      Oswald Buddenhagen authored
      no-one ever queried this state since S60 support was removed in
      ae23d505 (2012).
      
      Change-Id: I3e05d90bb43514b4c326e124834cf9c5e89a0168
      Reviewed-by: Tobias Hunger's avatarTobias Hunger <tobias.hunger@qt.io>
      Reviewed-by: Christian Kandeler's avatarChristian Kandeler <christian.kandeler@qt.io>
      fde9758f
    • Oswald Buddenhagen's avatar
      remove pretenses of support for DEPLOYMENT with .sources · 3c43c351
      Oswald Buddenhagen authored
      since fa6d0f12, DEPLOYMENT is aliased to INSTALLS, so we would have to
      actually look for .sources in entries listed in that variable, which we
      didn't. apparently, nobody noticed, among other things possibly because
      the qt4 variant already supports .files in later versions.
      also, our actual deployment code doesn't use .sources, either.
      
      Change-Id: I990240716817118047fc9aa97eff55305fcf7eca
      Reviewed-by: Tobias Hunger's avatarTobias Hunger <tobias.hunger@qt.io>
      Reviewed-by: Christian Kandeler's avatarChristian Kandeler <christian.kandeler@qt.io>
      3c43c351
  10. 25 Oct, 2016 1 commit
  11. 29 Sep, 2016 1 commit
  12. 26 Sep, 2016 1 commit
  13. 30 Mar, 2016 1 commit
  14. 24 Mar, 2016 1 commit
  15. 17 Mar, 2016 1 commit
  16. 16 Feb, 2016 2 commits
  17. 19 Jan, 2016 2 commits
  18. 14 Jan, 2016 1 commit
  19. 09 Nov, 2015 1 commit
  20. 03 Nov, 2015 1 commit
  21. 30 Oct, 2015 1 commit
  22. 16 Sep, 2015 1 commit
  23. 02 Sep, 2015 1 commit
  24. 21 Aug, 2015 1 commit
  25. 18 Aug, 2015 1 commit