Update: The same thing happens on another PC, with the same project. Also tested another, way smaller C++ project - semantic highlighting works there! Restarting QtCreator has no effect. The highlighting worked for the problematic project with the older QtCreator version 4.8.x.
It looks like the QtCreatorDeployment.txt file is only taken into account by CMake Project or Generic Project.
So I created a Generic Project, add the Python file(s) to the .files file, removed all the steps from the Build Settings tab, and configured the Run Settings with a Custom Executable where I set python as the remote executable, and main.py as the command line arguments while enabling Forward to local display.
Thanks again, I've got it working the way I want, though I had to do some extra things.
For completeness and others:
What happens is that if I use your example, the listing.qrc file is created the first time, and not on every build. If I use a fake file as output, the custom compiler is executed everytime, however, when the listing.qrc already exists, and due to not being the output it is probably?? not seen as a pre-target for RCC so it is executed before the custom compiler.
I've tried to add a depends_command or a dependency to a custom target in which I remove the file. Removal of the file works, but now the custom compiler is stuck in a loop it seems. Not entirely sure why.
What seems to work, is to have the files for the custom command explicitly listed in the input, which even makes sense, no input file change, no need to build. But, since the files are created outside the QT project, I do not have a full/explicit listing.
Using $$files(path/*, true) works to get the listing, but now there are many warnings like:
Makefile:1379: warning: overriding commands for target `../../Project/ui/ui.web/listing.qrc'
Makefile:1376: warning: ignoring old commands for target `../../Project/ui/ui.web/listing.qrc'
To get rid of this warning I added the combine option, since there are many inputs but only one output, which again makes sense.
So now I have a setup which only executes the custom command if the input files have changes, or if the output file is missing.
Also, I compile my programs with CONFIG -= debug_and_release on Windows, which simplifies the output folders (no extra debug and release subfolders). Note that this is only safe with shadow-builds, as on Windows debug and release objects cannot be mixed (another nice source for hard-to-track errors).
That would save you from these $$OUT_PWD/(debug|release) constructs - but you'd need to adjust other build system parts probably.
I faced the same problem with QtCreator 4.9.0 (32-bit, based on Qt 5.12.2) on Windows 10 ver. 1803 (build 17134.472).
For me, switching to python 3(.7.2) made it worse: gdb failed to even start with "Unable to create a debugging engine." in the "Application output" log.
Unsetting the PYTHONPATH env.var. solved it for me (for either a py2 or a py3 main "system" install).
If you need it for some other application (as I did), launching from e.g. a batch file you can set PYTHONPATH for the other app only or, alternatively, unset it (set to empty value) for QtCreator only.
For having PYTHONHOME set (e.g. to "C:\Python27" for python 2.7) and PATH containing the "system" python path (e.g. "C:\Python27;C:\Python27\Scripts;" for python 2.7) I noticed no problem.
Explanation Possible explanation:
The debugger was able to load its python bindings and modules and work (seemingly) correctly when I uninstalled all of my "system" python.
That – together with my initial observation – tells me that my QtCreator uses python 2 with its own set of libraries/modules which got overridden by my "system" python libraries/modules by having PYTHONPATH set, and gdb did not find its own python modules.
There might actually be a problem in gdb or QtCreator, as according to the debugger log –
– gdb seems to add its module paths dynamically to sys.path, which should take place after the effect of the PYTHONPATH env.var., so its value should probably not cause a problem. Could its behavior here be intentionally different to the python docs on env.var.s ?...
@aha_1980 the output is in red, which I think means it knows it is an error.
Here is a sample:
19:31:18: Running steps for project helloworld...
19:31:18: Starting: "/usr/bin/ninja" 3>&1 1>&2 2>&3
[1/3] Generating version.h with a custom command.
[2/3] Compiling C object 'helloworld_debug@exe/src_main.c.o'.
../../src/main.c:85:5: note: each undeclared identifier is reported only once for each function it appears in
ninja: build stopped: subcommand failed.
19:31:19: The process "/usr/bin/ninja" exited with code 1.
Error while building/deploying project helloworld (kit: ARM Bare Metal)
The kit ARM Bare Metal has configuration issues which might be the root cause for this problem.
When executing step "Custom Process Step"
19:31:19: Elapsed time: 00:01.
Looking more closely at the output, I see that it clearly says "The kit ARM Bare Metal has configuration issues which might be the root cause for this problem."
I hadn't configured the compiler in the Kits section of the options.
Having set the compiler correctly, it is now parsing the output! I should have spotted that earlier.
Sorry for resurrecting an old thread.
I had exactly the same problem as @kgregory and managed to get something working by cloning https://github.com/qt-creator/qt-creator , removing the relevant 2 lines from src/plugins/texteditor/texteditor.cpp and building it with qmake -r ; make -j8.
Column editing works now for me on macOS Mojave 10.14.4, the way I was used to it on Linux with Opt+Shift+Arrow keys.
Of course this overwrites the standard functionality of these combinations on a mac, but I consider column editing far superior. If overwriting the standard combinations is the only downside of this solution, I would like to propose making it default.
@aha_1980 a couple years ago, with considerable help from SGaist, I was able to configure and build Qt for the BeagleBone Black, and do cross builds and cross debugging. But that was a bit less formidable, as the BBB runs Linux, so the gdbserver was already supplied.
I realize that Creator is a very small part of Qt-dom in the eyes of the Qt community, but it's still the best damn editor and debugger interface I've ever used. It has plenty of value as a stand-alone product.