The logic for mapping files to targets is a heuristic, and a pretty bad
one. Add some logging output, which can be enabled by setting the env
variable QT_LOGGING_RULES to
qtc.cmakeprojectmanager.filetargetmapping.debug=true . This will allow
easier debugging of problematic cases.
Change-Id: I17086a30beb8962333109fce9198edde4540d169
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Instead of requiring that the target's source directory is a parent of
all source files, use a distance between the source and directory and
the file. This will find the wrong CMakeLists.txt in more cases but also
is much more likely to lead to using the fallback target.
This makes code completion work for http://github.com/dream3d/dream3d/
Change-Id: Ic035454c5eabe361bc7c46bd943e9a9cdee730e3
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Ignore targets that have no include directories, those are in general
not targets that are very useful.
Change-Id: I1cd1f7dffc73eace2f7a0897bc15dea7e6bc5fee
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
The affected cmake projects have the CMakeLists.txt in a subdirectory
of the project's root. We can't figure out the right project part in
that case. Falling back to the "all" target is wrong though, since
that has not every include path. Instead search for a good target
that has more include paths.
Change-Id: I1a874042fcb9533888a41c001fbf8adc2aa90a39
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
This fixes regression 65c113bcbc that caused
files to be likely assigned to "all" target when all CMake targets were having
sources residing in same directory using Ninja generator. As "all" came first
then it became best match in such case.
This introduces slight modification, so target with most include paths is
chosen from these having best file system proximity to source file. Doing so we
select likely real target and get all #include preprocessor directives resolved
properly in the editor.
Change-Id: Ifb85bb5954b4cf5618a6d8444c993c69ebab2259
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Stephen Kelly <steveire@gmail.com>
This can use the faster route through QFileInfo::exist now.
Change-Id: Idb41b5d5185d7f02eacba498fb01f483d95e8d57
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
All static functions, can live closer to related code.
Change-Id: I54c5680256c78f1d09b4bee3e8843b2f4350b75a
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Allow multiple expanders to be registered for lineedits, e.g. a
local and the global ones, and actually show them.
Use a tree view in the chooser for somewhat more structured display.
Change-Id: I769f92144e5249f45e54381de52aa6973eb20118
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
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>
