1. 31 Jul, 2017 1 commit
  2. 05 Dec, 2016 1 commit
  3. 26 Aug, 2016 1 commit
  4. 15 Apr, 2016 1 commit
  5. 30 Mar, 2016 1 commit
  6. 08 Feb, 2016 1 commit
  7. 03 Feb, 2016 1 commit
  8. 01 Feb, 2016 1 commit
  9. 29 Jan, 2016 1 commit
  10. 19 Jan, 2016 1 commit
  11. 16 Nov, 2015 2 commits
  12. 23 Oct, 2015 1 commit
  13. 20 Oct, 2015 1 commit
    • Ulf Hermann's avatar
      Introduce Profile build mode · 69377f0d
      Ulf Hermann authored
      We define a Profile build to be a Release build with separate debug
      info. You can thus change a given build from Release to Profile of vice
      versa by toggling the separate debug info checkbox. The messaging for
      future user interaction about Profile builds has to take this into
      Task-number: QTCREATORBUG-14009
      Change-Id: I62a5b13993b20bf36329b1eefa8b1b6096f31644
      Reviewed-by: default avatarTobias Hunger <tobias.hunger@theqtcompany.com>
  14. 13 Feb, 2015 1 commit
    • Daniel Teske's avatar
      Android: Set correct ANDROID_NDK_PLATFORM · e7b90b86
      Daniel Teske authored
      Introduce the class AndroidQmakeBuildConfiguration whose purpose is
      to set the environment variable. Modify the Factory to create
      buildconfigurations of that type and fix restore/clone to also
      take the factories' priorities into account.
      Change-Id: Icb377fa9211cd3564c36b60cf7c5f7dd84fcab50
      Reviewed-by: default avatarBogDan Vatra <bogdan@kde.org>
  15. 16 Jan, 2015 1 commit
  16. 05 Nov, 2014 2 commits
  17. 23 Oct, 2014 1 commit
  18. 16 Oct, 2014 1 commit
  19. 14 Oct, 2014 1 commit
  20. 09 Oct, 2014 1 commit
  21. 21 Jul, 2014 1 commit
  22. 01 Jul, 2014 1 commit
    • Christian Kandeler's avatar
      Always pass Core::Id by value. · 93304df0
      Christian Kandeler authored
      Currently we pass in some places by value, elsewhere by const ref and
      for some weird reason also by const value in a lot of places. The latter
      is particularly annoying, as it is also used in interfaces and therefore
      forces all implementors to do the same, since leaving the "const" off is
      causing compiler warnings with MSVC.
      Change-Id: I65b87dc3cce0986b8a55ff6119cb752361027803
      Reviewed-by: default avatarhjk <hjk121@nokiamail.com>
  23. 08 Jan, 2014 1 commit
  24. 01 Oct, 2013 1 commit
    • Tobias Hunger's avatar
      BuildConfigurationFactory: Introduce priorities · ac6a3fd5
      Tobias Hunger authored
      Introduce priorities for build configuration factories. This way
      plugins can register specialized build configuration factories, that
      e.g. can provide additional build steps.
      A negative priority signifies that a factory is not prepared to
      handle a request, the default build configuration factory shipped by
      the build system plugin will report a priority of 0. Add 100 to that
      for each specialization you add (e.g. a remote linux buildconfiguration
      factory would report 100, a specialization of that for mer will
      should report 200, etc.).
      Change-Id: I141a7a5a79166afdb7657d46eb7e86bd18d3abf6
      Reviewed-by: default avatarDaniel Teske <daniel.teske@digia.com>
      Reviewed-by: default avatarMichal Klocek <michal.klocek@digia.com>
  25. 27 Sep, 2013 1 commit
    • Tobias Hunger's avatar
      TargetSetupPage: Generalize the page · 921f86df
      Tobias Hunger authored
      Generalize the target setup page and move it into projectexplorer
      Move the qmake specific code into a projectimporter class with
      a specialization for qmake projects in the qt4projectmanager.
      This change depends heavily on the BuildConfigurationFactory cleanups
      done earlier and completes that change in such a way that generic
      build configuration factories are now in theory possible. The
      remaining problem is how to select the best factory of several that
      claim to be able to handle a kit and that is left for the next patch.
      Change-Id: I47134cb1938c52adebcdc1ddfe8dbf26abbbbeee
      Reviewed-by: default avatarDaniel Teske <daniel.teske@digia.com>
  26. 17 Sep, 2013 1 commit
    • Tobias Hunger's avatar
      BuildConfigurationFactory: Refactor code · d2adc303
      Tobias Hunger authored
      Refactor the code of the build configuration factories. The idea is to
      generalize the code so much that we can allow plugins to install
      custom build configuration factories for the platforms they support.
      To support this use case the following changes where done here:
       * BuildInfo class was introduced to describe one build configuration that
         can be created by a factory.
       * Factories report a list of BuildInfo to describe what they can produce.
         This fixes the need for factories to implicitly create one buildconfiguration
         and then create another one 'officially' to support debug and release build
         configurations to be set up for projects.
       * Do no longer work around factories to create build configurations.
      Change-Id: Ic372e4a9b5c582633b467d130538948472b89d91
      Reviewed-by: default avatarDaniel Teske <daniel.teske@digia.com>
  27. 28 Aug, 2013 1 commit
  28. 19 Apr, 2013 1 commit
  29. 26 Mar, 2013 1 commit
  30. 11 Mar, 2013 1 commit
    • Christian Kandeler's avatar
      ProjectExplorer: Make fromMap() public in BuildConfiguration. · 5977b6db
      Christian Kandeler authored
      And also in DeployConfiguration.
      Rationale: Consider this typical use case of a deploy configuration
      factory that can create several deploy configurations for a specific
      ProjectExplorer::DeployConfiguration *MyFactory::restore(map)
          ProjectExplorer::DeployConfiguration *dc = 0;
          id = idFromMap(map)
          if (id == myDcId_1())
              dc = new MyDcId_1;
          else if (id == myDcId_2())
              dc = new MyDcId_2;
          else if (id == myDcId_n())
              dc = new MyDcId_n;
          if (dc)
          return dc;
      This does currently not compile, forcing us to introduce n variables and
      calling fromMap() n times. In addition, we either have to make the
      factory a friend of all the deploy configurations or add a public
      fromMap() function into all of them, even if they don't add any
      functionality, or introduce some other type of silly boiler-plate code.
      All of this becomes unnecessary when fromMap() is public in the parent class.
      Note also that fromMap() is public in the inheritance root
      (ProjectConfiguration) as well as in RunConfiguration.
      Change-Id: I4c6431bba2500e2434c487c316e30ddb259fa2b5
      Reviewed-by: default avatarDaniel Teske <daniel.teske@digia.com>
  31. 29 Jan, 2013 1 commit
  32. 16 Nov, 2012 3 commits
  33. 02 Nov, 2012 1 commit
  34. 22 Oct, 2012 3 commits