Why does Qt Creator need a kit for non-qt cmake project - qt-creator

I selected a Non-Qt C++ project from File->New, and then CMake for the build system, yet Qt Creator still insists that I specify a Qt kit.
I know for qmake projects you need a kit for the qmake, but why does it need it for cmake? The project itself won't use qt or qmake, I just want to use Qt Creator as the IDE. Also would specifying a kit make a dependency on Qt?

You are free to have kits in Qt Creator with or without Qt, with or without a C++ compiler, with or without cmake binaries, etc.
Qt Creator uses kits as a collection of things that are used together in (multiple) projects, so that you do not have to define these same settings again and again. The settings available in a kit depend on the plugins you have enabled and Creator is perfectly happy if some information is not set -- as long as this information is not needed by the project you are working on. So if you open a qmake-based project, creator will complain if a kit has no Qt version set (which is what provides the qmake binary). If you try to open a cmake-based project, then Creator will complain about Kits without a cmake binary set up. Kits are in no way limited to qmake projects, but does also apply to cmake, autotools, nim, python projects (and whatever else is supported;-).
For CMake projects the Kit defines the cmake binary to use, the Generator to use with that binary, default values to pass to cmake, the compiler used by the code model built into Qt Creator (and by the cmake project itself in newer Qt Creator versions), the Qt version that is used by the code model (and by the cmake project in newer QtC versions), the default environment the project will see when building and some more things.

Related

Loading OpenSSL dynamic libraries arm & x86 (FMX, C++)

I am able to use OpenSSL static libraries (libcrypto.a and libssl.a) in my iOS app thanks to this help. Now i can also use OpenSSL dynamic libraries (libcrypto.so and libssl.so) in my Android app version thanks to this info. I downloaded the files for Android in the OpenSSL_1.0.2g_Android.zip file from here. I just guessed and used the ARM files (armeabi-v7a folder) instead of the Intel files (x86 folder) and it worked on my Android test phone.
My question: How do I make an Android build that uses the correct library files on ARM devices AND also on Intel? I don't know how to deploy both sets of files for this. Below is snip of project window showing where i test added the second libcrytpo.so library file for x86.
But, this second libcrypto.so does not show up in the deployment window, only the first version i added (the ARM version) remains.
I was hoping i could somehow use compiler directives but maybe i just need 2 independent projects altogether? One built for Android ARM and other for Android x86? Further, all i'm needing in my code is an IdHTTP1->Get() so maybe their is a way i can use the built in BoringSSL fork? If so, how?
russ
C++Builder 10.3 Version 26.0.33219.4899
RAD Studio does not support producing Android apps for Intel, only for ARM, so don't even worry about trying to use the x86 libs on Android.
Also, Indy does not support BoringSSL at this time.

How to enable C++11 support in generic project in Qt Creator 2.8.0?

I know that Qt Creator can recognize C++11 in Cmake and QT projects, but how to activate it in generic projects (e.g. created by "import existing project" option)? It's not enabled by default (e.g. autocomplete doesn't work for C++11 classes such as std::shared_ptr etc).
This was fixed quite a while ago for the 3.0 release: https://codereview.qt-project.org/#change,62536
This should be working now just fine as per the Gerrit comment:
Generic project manager: assume C++11 for cxxVersion.

How do you configure Qt Creator to use both Qt4 and Qt5?

I download Qt Creator 2.7.0 (Based on Qt 5.0.2 (64 bit)).
This seems to compile everything with Qt5.
I know you can download the Qt4 SDK, but then how can i configure projects to use Qt4 instead if I need to? Please provide detailed instructions. I'm on Ubuntu and not using any repository supplied Qt tools/libraries.
Answer: You download Qt4, compile it (if necessary) then in the menu Tools->Options->Build & Run->Qt Versions, you add Qt4 manually similar to the Qt5 config. You just need the path to the qmake file. Then go to the Kits tab in the same Options box, and add a manual Qt 4 Kit. You can change the Kit available to your app via the Projects tile and the Add Kit button. Add the Qt4 kit, remove the Qt5 kit, rebuild all. Simple.
ref: http://doc.qt.io/qtcreator/creator-targets.html

Use MacOSX framework compiled with different version

From what I've heard, it's possible to use a DLL in Windows that is compiled with a different compiler version. Does MacOSX frameworks have the same functionality? That is, can I compile a framework with one compiler and then use that framework in a program that uses a different compiler version?
The reason why I ask is that need to compile a open source project that outputs a framework. That project is not possible to build with gcc4.7 and my code uses gcc4.7 features.

Use Mono for android on with Mono

It looks really easy to switch MonoDevelop's compiler to Mono tools instead of .NET – you just need to pick a different framework under settings of the IDE.
However, after switching to Mono and getting the project compiling by Mono tools, Mono for android no longer seems to be an available framework (i.e. the reference to it in the Android project turns red). Obviously, the build fails with tons of errors like Android.XXX.YYY is not a class or namespace name, etc.
Is there a way to install Mono for android on a Windows machine so that it is available to Mono tools and usable from Monodevelop running on Mono?
No. Mono for Android uses the MSBuild build system, and installs custom build tasks and frameworks into the MSBuild extension directories. Mono's implementation of MSBuild (xbuild) has separate extension directories. It might be possible to copy the targets and extensions across but you'd probably run into other issues, as it's completely untested.
In general on Windows I'd recommend using the MS/.NET toolchain in MonoDevelop unless you have a really good reason to use the Mono toolchain. Note that you can run with Mono even if you compile with .NET, using the Run->Run with... menu.

Resources