1. 12 Feb, 2014 1 commit
    • Orgad Shaneh's avatar
      Clean up single namespace forward-declarations · 7ed15760
      Orgad Shaneh authored
      Done using the following ruby script:
      
      Dir.glob('**/*.h').each { |file|
        if File.file?(file)
          s = File.read(file)
          t = s.gsub(/^namespace .+ \{\n\s*class .*;\n\s*\}.*$/) { |m| m.gsub(/\n\s*/, ' ').gsub(/\s*\/\/.*$/, '') }
          if t != s
            puts file
            File.open(file, 'w').write(t)
          end
        end
      }
      
      Change-Id: Iffcb966e90eb8e1a625eccd5dd0b94f000ae368e
      Reviewed-by: default avatarhjk <hjk121@nokiamail.com>
      7ed15760
  2. 11 Feb, 2014 1 commit
  3. 10 Feb, 2014 2 commits
  4. 24 Jan, 2014 1 commit
  5. 14 Jan, 2014 1 commit
  6. 10 Jan, 2014 2 commits
  7. 09 Jan, 2014 1 commit
  8. 08 Jan, 2014 3 commits
  9. 06 Jan, 2014 1 commit
  10. 18 Dec, 2013 1 commit
  11. 12 Dec, 2013 2 commits
  12. 10 Dec, 2013 2 commits
  13. 25 Nov, 2013 1 commit
  14. 14 Nov, 2013 2 commits
  15. 13 Nov, 2013 1 commit
  16. 04 Nov, 2013 1 commit
  17. 24 Oct, 2013 1 commit
  18. 22 Oct, 2013 1 commit
  19. 16 Oct, 2013 1 commit
  20. 14 Oct, 2013 1 commit
  21. 10 Oct, 2013 1 commit
  22. 09 Oct, 2013 2 commits
  23. 01 Oct, 2013 3 commits
  24. 27 Sep, 2013 2 commits
    • hjk's avatar
      Use the canonical version of defining string literals · f17d9f01
      hjk authored
      Change-Id: If36658de6f68f552f93830ba4f1cfa9994a2e44c
      Reviewed-by: default avatarTobias Hunger <tobias.hunger@digia.com>
      f17d9f01
    • 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>
      921f86df
  25. 20 Sep, 2013 1 commit
  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>
      d2adc303
  27. 16 Sep, 2013 1 commit
    • Oleksii Serdiuk's avatar
      CMake: Make CMake plugin work with RemoteLinux plugin. · 328a24ed
      Oleksii Serdiuk authored
      Modified CMake plugin to work correctly with RemoteLinux plugin.
      Because of not being able to extract files to be installed from CMake
      project, only executable targets are automatically added to deployment
      files. All other files have to be specified in CMakeDeployment.txt file
      which should be placed into root of CMake project. The file format is:
      > deployment/prefix
      > relative/source/file1:relative/destination/dir1
      > ...
      > relative/source/filen:relative/destination/dirn
      
      Where:
      - deployment/prefix is (absolute) path prefix to which files will be
        deployed on the remote machine.
      - relative/source/file is file path relative to CMake project root.
        Plain files - no directories or wildcards supported.
      - relative/destination/dir is destination directory path relative to
        deployment/prefix.
      
      Change-Id: I0831636c1b9aac3ff16bb6293104c512d2abfb5a
      Reviewed-by: default avatarDaniel Teske <daniel.teske@digia.com>
      328a24ed
  28. 12 Sep, 2013 2 commits