Replace the CppModelManagerInterface/derived CppModelManager
combo by a more common CppModelManager/CppModelManagerPrivate
pimpl pattern.
Change-Id: Ia4582845ed94d5ef60b8571bab9b2260c6290287
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
So that recalculating the information is not O(n^2) but linear.
Change-Id: I69903e0b5ad321d071804d782ad634a3f300e71a
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
The current approach fails for all build systems where one project file
can define more than one executable.
Change-Id: Ieda413975709fbd6e7ea87b185aa962f63cb7c1f
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
This is in preparation for changes to the ProjectParts, where one part
can only hold files for 1 language.
Change-Id: I669e4f5b20e6553caad3a9ea2ed0e7c4455a8db7
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
This was introduced by adding the remote linux support for 3.0 in
328a24edee. If the user cancels the
run cmake dialog, no buildconfiguration is created. The adding of kit
should then not happen. A target without a buildconfiguration should
not happen.
Task-number: QTCREATORBUG-12773
Change-Id: Ic43c5cc13f9e114ea24cc97154a6c084125f6318
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
The only project manager that actually sometimes changes the displayname
is the cmake project manager. And that one failed to emit the right
signal. And since the signal was never emitted a few places handled the
signal wrongly.
Change-Id: I4aa75dc3032efe49263143dbadb7585a378b9be9
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
While we do know all the parts, we don't know to which part each file
belongs. So we guess that based on file system proximity.
Task-number: QTCREATORBUG-12359
Change-Id: I9d2a2ca0171b4e43f4a65d2f4b7b318f4e8b451c
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Since we want to treat them differently.
Task-number: QTCREATORBUG-12461
Change-Id: Ia72b8045390ceec693fa416f65010a4c4dbecce1
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Instead of having two lists of paths, now only one list is used where
both include paths and framework paths can be mixed. This reflects the
way the compiler is invoked, and retains the (correct) search order.
Task-number: QTCREATORBUG-11599
Change-Id: I373953e3e305df5b7a0d10920e12d146584adf9f
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
Fix potential index out of range assertion in QStringList if contents of
QtCreatorDeployment.txt would be unexpected(will not contain ':')
Change-Id: Ia6ae282ef450e7c56a512b13da801854caec0dfb
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Move item model implementation to private, adjust user code.
Change-Id: Ifbe94e7c7b9b1e8be1b4c531958dbd7a9413af13
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
CodeBlocks is utterly ignorant of frameworks on Mac, and won't report
framework paths. The work-around is to check if the include path ends in
".framework", and if so, add the parent directory as framework path.
Task-number: QTCREATORBUG-11445
Change-Id: I794dd72d755d5593e36ebf59543d0a5e9fda3cce
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Which compares two sorted lists and returns a diff between them.
Change-Id: I278bd43f1bd999bae6575cbf38cddbdf3ff82418
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
The reason they were on ProjectNode is that the signals are emitted
on the projectnode, but since I moved addFiles and others to FolderNode,
this makes more sense.
Change-Id: I918ca4d93dab78c8bb93dff03f53d1a6fbe21340
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
So we can ignore possibly problematic toolchain-defines, while can still
unconditionally apply project-defines.
Change-Id: I7cb96f35a963d080011fe888ef71bfc098dd33ef
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
Add displayname and project file path and a pointer back to the
project.
Change-Id: Ic9a18f52a6291493bd3a95fd3456ed0e1a3c63e3
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
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: Daniel Teske <daniel.teske@digia.com>
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: Daniel Teske <daniel.teske@digia.com>
* Update build targets as they change in CMakeLists.txt
* Do not set "all" since that is the default anyway
* Signal widget whenever the list of targets to build changes
Change-Id: Ie90be143fa345e03576632ab39a5dc5f75b19daf
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Use setBuildDirectory() in the different BuildConfigurations instead
of reimplementing that over and over again.
Change-Id: Ic355fdb4624c71667ce470b3e2865c9a8722ef09
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
This introduces an API change for the project managers. Those are not
expected to call updateSourceFiles() anymore.
Task-number: QTCREATORBUG-9581
Change-Id: I77befd29fb851c9acf87204d571da00183c9cd05
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
