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>
The display name is not editor instance specific, but belongs to the
document.
Change-Id: I3c936f04a86e10e6ca30063d85036d85b4b5880e
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
* Move basic ui code model support from CppTools into QtSupport
* Use Kit infrastructure to retrieve uicCommand and environment
* Remove specialization for cmake projects (no longer needed)
* Remove specialization for qmake based projects (no longer needed)
Change-Id: I8569cc01acb46a540883c2da235d169bebf7db39
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
That is what it actually is, wrt how Qt API calls it.
Change-Id: Ied02055debf6aad75556b0d9d22e8ba2f72be555
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Instead of requiring subclasses to implement a method.
Also renames IDocument::rename to IDocument::setFileName,
since it doesn't really rename any files or such.
Change-Id: I1344025c24d2f74a6a983e04fb0a5245f1f37aad
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
We set the display name for cmake projects based on the projects's
name in the cdb file. The parsing of that happens quite late, so
we need to set a fallback displayname in the ctor.
Task-number: QTCREATORBUG-9641
Change-Id: Iabfef7a3cc9710e6ba04523845d4142a89493011
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
...so parsing progress will also be reported for projects consisting of
only one source file.
Task-number: QTCREATORBUG-9597
Change-Id: If35a00b6f949258d64921f144919269fa0c81d36
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Now it uses ProjectPart::evaluateToolchain() to read toolchain info with
given compiler flags, so it saves old behavior and also reads C version
and C++ extensions.
Removed check that model doesn't need to be updated, since check didn't
account ProjectPart enums.
Change-Id: I6dbebeecdb162ec5b885f9f1846756b586c22b23
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Now it provides information about C language standard and C++
extensions. No new behavior added to project managers.
Change-Id: Ib7c19641f452a75c9b14cd7e33d104dcd1603720
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
If a qt version does not support shadow building, this just means that
the qmake for that qt is broken. That has no bearing on whether cmake
could shadow build.
Change-Id: If2b69b42094d87cd0c3be26d043e344aa8b370da
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
In recent CMake versions, a new backend, Ninja, was added with the intention
of providing an alternative to makefiles. However, this backend stores the
CXXFLAGS for the project in a different format than it does for the makefiles
backends. As the CMakeProjectManager assumes a makefile backend, it fails
to correctly obtain the CXXFLAGS of the project when Ninja is used.
This small patch will attempt to read CXXFLAGS from the build.ninja file
to correct this issue.
Task-number: QTCREATORBUG-9047
Change-Id: Ic19ae3b4802c7a12b5d0a92a7f1a2254bec5a3d2
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
