Qt Creator and other tools

@VRonin said in Integrating Qt Test and Appveyor: @Violet-Giraffe Interesting, all the times I tried appveyor would refuse my second upload and fail the build. Since when do you have that project doing multiple uploads? It might be a new feature It could be new, I had that thought as well. I'm doing it since two days ago so I cannot testify that's how it always used to work.

@JonB said in Login: qDebug(qry.lastError()); qDebug() << qry.lastError();

I've found a way! I analyzed Creator's sources and saw that project parts are bound to MIME type. To treat .c files as C++ you only need to edit MIME settings: In main menu go to Tools->Options->Environment->Mime Types Edit "text/x-c++src" entry and modify its pattern to match .c files Edit "text/x-csr" and clear it's pattern. Now you'll get a single project part and all the Code Model will treat files as valid C++ files!

I've just installed Qt Creator 4.6.2 on Windows 10 and when I tried to build the first project I've also experienced a similar problem. Here's Qt Creator's output: C:\Program Files\CMake\share\cmake-3.12\Modules\CMakeTestCCompiler.cmake:52: error: The C compiler "C:/Program Files (x86)/Microsoft Visual Studio/2017/BuildTools/VC/Tools/MSVC/14.14.26428/bin/HostX86/x64/cl.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/Users/rmam/AppData/Local/Temp/QtCreator-WwNhAr/qtc-cmake-cZffZkom/CMakeFiles/CMakeTmp Run Build Command:"jom" "/nologo" "cmTC_2b1c8\fast" The system cannot find the file specified Generator: execution of make failed. Make command was: "jom" "/nologo" "cmTC_2b1c8\fast" edit: after adding Qt Creator's bin directory to the system path ( i.e. if Qt is installed in C:\Qt then it's C:\Qt\Tools\QtCreator\bin ) the build proceeded as expected. This agrees with Qt's FAQ entry on Qt Creator not finding a helper application, such as Git or a compiler, which suggests checking if the application is in the system PATH. Qt Creator enables users to add entries to the PATH environment variable that are specific to each cmake project through the "Projects" menu -> "Build", and in the bottom part of the form in the "Build Environment" section click on "Details" and add entries to the PATH environment variable. Having said that, how exactly can Qt Creator fail to include Qt Creator's bin folder in Qt Creator's PATH environment variable?

Your listing does not contain any error message. Search for it above the given output. Qt Creator build questions are best asked on Qt Creator mailing list. That's where devs working on it reside.

@mzimmers Just so you know, all debuggers on all platforms (have to) work like this when debugging a UI-event-driven application. When stepping/running to next breakpoint, it executes only the instructions it comes across, and while they do not allow the UI to process events/repaint the visuals will remain "frozen". It actually shows you what what is really going on in your app! Like @J-Hilk says, only way is temporarily to insert necessary event processing lines into the code you happen to be stepping through. Not ideal for debugging, but a standard issue.

Why do you have your plugins and application all in the same project ?

Hi @fyngyrz, no it's a directory. I now found out, that a *.qws file is created for each session, e.g. ~/.config/QtProject/qtcreator/test.qws. Don't know if Creator will complain if you make this file read-only. Another idea: Have you thought of using bookmarks? Regards

@cesar93 so if your problem is solved, please mark this topic as SOLVED too. Thanks

@aha_1980 Get it! Update is done, i can see the option Heob in Analyze category. I check Heob install now... Thanks a lot for the reply. Regards loup

@Sacha_D For developing it is always safe to use paths with ASCII characters and without spaces.

This lead to QTCREATORBUG-20605, please use that for further tracking. Therefore closing this topic.

One more thing: this should have been one of my first things I tried, but I ran the debugger and got the following message - "The inferior stopped because it received a signal from the operating system Signal name: SIGSEGV Signal meaning: Segmentation fault", and it pointed directly at my destructor for DataPiece, which simply calls "delete this" (even though I never actually call the destructor in my code, it must be an implicit call). After briefly looking up this error, I primitively discovered that this generally occurs when attempting to illegally access a register in memory. So then I looked at how I initialized my DataPiece, realizing that I actually wasn't calling any of my constructors. So, I passed it a parameter 'this' to act as the QObject * parent, but this still didn't resolve my SIGSEGV issue. Any thoughts?

@Mark81 said in Debugger doesn't show the source of the error: I understood if I compiled Qt in debug mode the debugger will show the Qt source code that would be unuseful. As I said, if it is the case that the fault is coming as a result of Qt code executed internally as an indirect consequence of something your code did earlier, what else do you expect to get out of a debugger? Yes, it will show the Qt code. Then in the debugger you can try to understand which list of yours is being accessed. P.S. I don't do cross-compilation, but I presume the way it works is that you are running a native debugger on the target machine (RPi). Are you sure that the source file paths are available to & valid paths from the target's POV?

@Anqi Adding to @SGaist when load the custom widget plugin, every slot function will be called? No. Creator/Desiner calls the QDesignerCustomWidgetInterface meta functions bool isContainer() const override; bool isInitialized() const override; QIcon icon() const override; QString domXml() const override; QString group() const override; QString includeFile() const override; QString name() const override; QString toolTip() const override; but unless you hooked your slots up to some signals that triggers during load, it wont call any slots as such. class QSerialPortInfo can't be init in custom widget plugin? You can use any class as you normally would. No restriction as such.

Well, eventually I found there were two sysroot folders, likely due to a typo in the scripts... hence it was searching in the wrong one.

Because I had the same Issues with the same Tutorial and often came along this discussion while searching for possible solutions, I took the privilege to dig up this old thread. With the help of What would be a pratical example of sysroot and prefix options for Qt and especially the mentioned option, quote:" -no-gcc-sysroot very specific hack for compilers that can't find their own crt inside --sysroot passes sysroot to pkgconfig and others, but not to gcc so that gcc will be called with -L/sysroot/lib/ correctly, but doesn't try to find implicit paths (crt) here. ", I was able to fix the problem.

No problem, you pointed me in the right direction in the first place, all about a good community!

@SGaist, The same as the original poster's one: Project ERROR: failed to parse default search paths from compiler output Error while parsing file path/to/project.pro. Giving up. Going to Build > Run qmake was failing too. After simply running qmake in the terminal, it started working. It was not creating the Run configuration at all, even after cleaning git ignored files (like the .pro.user file for example) and configuring a Build configuration.