1. 13 Dec, 2017 7 commits
  2. 12 Dec, 2017 21 commits
  3. 11 Dec, 2017 7 commits
  4. 09 Dec, 2017 2 commits
  5. 08 Dec, 2017 3 commits
    • hjk's avatar
      ProjectExplorer/all: Re-organize BuildSteps/{Deploy,Build}Config setup · 53a15107
      hjk authored
      This follow the rough pattern of recent *RunConfigurationFactory changes
      for build and deploy configurations.
      - Collapse the two lines of constructors similar to what
       did for RunConfigurations
        * Deploy* was purely mechanical
        * Build* ctors are split in connects() in the ctor body
          to create "empty shell for clone" etc
          and build step additions in initialize() functions which
          are only used in the create() case.
        -- Allows to collapse the shared 'ctor()' functions, too.
      - Move FooBuildConfigurationFactory::create() implementations
        to FooBuildConfiguration() constructor. That was a strange
        and unneeded ping-pong between factories and objects, and
        furthermore allows one level less of indirection (and for a
        later, left out here, some reduction of the
        FooBuildConfiguration interfaces that were only used to
        accommodate the *Factory::create() functions.
      - Most {Build,Deploy}Configuration{,Factory} classes had a canHandle(),
        but there wasn't one in the base classses. Have one there.
      - Most canHandle() functions were checking simple restrictions on
        e.g. project or target types, specify those by setters in the
        constructors instead and check them in the base canHandle()
      - clone() is generally replaced by a creation of a "shell object"
        and a fromMap(source->toMap()), implemented in the base, there
        are two cases left for Android and Qbs that needed(?) some extra
      - generally use canHandle() in base implementation, instead
        of doing that in all Derived::canFoo()
      - as a result, canCreate/create/canClone/clone reimplementations
        are not needed anymore, keep the base implementation for
        now (could be inlined into their only users later), but
        de-virtualize them.
      - Combine Ios{Preset,DSym}BuildStepFactory. There was only one
        'dsym' build step they could create.
      - Split the 'mangled' id into the ProjectConfiguration subtype
        specific constant identifier, and a QString extraId() bit.
        Only maintain the mangled id in saved settings.
      - Make ProjectConfiguration::m_id a constant member, adapt
        all constructors of derived classe.
      Not done in this patch:
      - Finish possible cosmetic changes on top
      - Add a way to specify restrictions to supported Qt versions
        (used in Android/Ios), as the base implementation does not
        depend on the qtsupport plugin
      - Combine the QList<X> availableFoo() + createFoo(X) function
        pairs to somthing like a direct
         QList<struct { X; std::function<X()>; }> fooCreators()
        to avoid e.g. the baseId.withSuffix() <-> id.suffixAfter(base)
      - Remove the *Factories from the global object pool
      - Do something about priority(). Falling back to plain
        qmake in android+qmake setup is not helpful.
      Change-Id: I2be7d88d554c5aa8b7db8edf5b93278e1ae0112a
      Reviewed-by: Tobias Hunger's avatarTobias Hunger <tobias.hunger@qt.io>
    • Tobias Hunger's avatar
      Session: Remove projectContainsFile · 9d3c5c6f
      Tobias Hunger authored
      Use Project::isKnownFile instead.
      Change-Id: If69e413e4603fe6d7dc359ecd55d6233d9a3a642
      Reviewed-by: Eike Ziller's avatarEike Ziller <eike.ziller@qt.io>
    • Tobias Hunger's avatar
      Session: Get rid of cache of all project file names · 43f57d3f
      Tobias Hunger authored
      Make the project responsible to provide information on which files
      belong to it instead.
      Change-Id: I80accf9104af33eaffc6b8f3e6024e9725697d37
      Reviewed-by: Eike Ziller's avatarEike Ziller <eike.ziller@qt.io>