Condition to auto detect installed Qt Versions in Qt Creator
-
wrote on 27 Sept 2017, 14:27 last edited by
I currently have multiple Qt Versions in Qt Creator running on Ubuntu. These are built for specific hardware variants (mainly ARM-based). So far I have added these versions manually to Qt Creator (Tools > Options > Build & Run > Qt Versions), but this is a step I would like to avoid if possible. My wish is to distribute these custom Qt Versions to other users within my company and not force them to manually add them. Just ask them to install (using viable methods) and they should appear in Qt Creator.
I know that Qt Versions can be detected automatically, but so far I have been unable to get hold of the information which states how these are actually detected and added automatically.
The following page only mentions this briefly:
“Qt Creator automatically detects the Qt versions that are registered by your system or by installers.”So my question is: how are Qt Versions registered on the system so they may be auto-detected by Qt Creator?
-
wrote on 28 Sept 2017, 12:22 last edited by
I believe I have come to an conclusion on this matter after using the sdktool and watched this presentation.
Auto-discovered Compilers/Versions/Kits are all added using the sdktool. There is no magic here sadly (which I hoped), they have to be added using this tool by passing the required arguments. Versions and Compiler (toolchain) may be added independently, but when a Kit is to be added, it has dependency both to added Version and Compiler (by unique IDs entered when adding them). Therefore they should preferably all be added using the same method.
These settings are also unique for the installed Qt Creator version. I guess there might be a difference depending on how you have installed Qt Creator. In my case it is built from source code directly, so these settings are stored in the build directory (making these settings unique for this Qt Creator). The presentation suggests that system-wide settings are stored under /usr/share/qtcreator/.
tldr; use sdktool to add auto-discoverable Compilers, Versions and Kits to Qt Creator.
-
wrote on 27 Sept 2017, 14:51 last edited by
Hi, my guess is in one of the files in the ~/config/QtProject/qtcreator folder
-
wrote on 27 Sept 2017, 15:25 last edited by
-
wrote on 28 Sept 2017, 07:20 last edited by jesperm
@hskoglund Thanks for the reply, it appears that you are on the right track according to this page. "profiles.xml" and "qtversions.xml" stores information about the kits and versions, but I'm actually having a hard time finding these exact files in my system. What I did find was ".../QtProject/qtcreator/profiles-original.xml" and it contains the information which is related to the auto discovery of kits.
One of the keys in the file is "<value type="bool" key="PE.Profile.AutoDetected">true</value>", I have seen other examples of this file on the Internet with the key set to "false". In my eyes this file is the result from a registered Qt Version, due to the naming of the key. I'll look further into this.
@Pablo-J.-Rogina Thanks for the direction. Looking at the source code was actually an idea I had from the start, but had no clue where to start looking. The file previously mentioned (profiles-original.xml) has a stamp written by the sdktool, so looking further into the sdktool seems to be the right call - if that tool generated the file, it should contain more information how the kits are actually discovered.
-
wrote on 28 Sept 2017, 12:22 last edited by
I believe I have come to an conclusion on this matter after using the sdktool and watched this presentation.
Auto-discovered Compilers/Versions/Kits are all added using the sdktool. There is no magic here sadly (which I hoped), they have to be added using this tool by passing the required arguments. Versions and Compiler (toolchain) may be added independently, but when a Kit is to be added, it has dependency both to added Version and Compiler (by unique IDs entered when adding them). Therefore they should preferably all be added using the same method.
These settings are also unique for the installed Qt Creator version. I guess there might be a difference depending on how you have installed Qt Creator. In my case it is built from source code directly, so these settings are stored in the build directory (making these settings unique for this Qt Creator). The presentation suggests that system-wide settings are stored under /usr/share/qtcreator/.
tldr; use sdktool to add auto-discoverable Compilers, Versions and Kits to Qt Creator.
-
wrote on 28 Sept 2017, 20:49 last edited by
Great that my presentation still helps out people:-)
There is no "global" configuration of stuff, everything is limited to one Qt Creator instance. /usr/share/qtcreator/... is just the default location for a system-wide installed instance of Creator on most Linux distributions.
The sdktool is indeed the best way to register toolchains/qt versions/kits/debuggers/... with one Qt Creator instance. It works by managing some xml files in ../share/qtcreator/QtProject (path is relative to the Qt Creator executable that the sdktool belongs to!).
The ids registered with the sdktool do not get randomized, so you can use it to set up a set of machines with kits that will work across the whole set.
You can symlink/copy the settings to new creator instances though by just placing the ../share/qtcreator/QtProject directory of one instance into the right place for another and it will be picked up by both instances and creator should watch the files and react to them changing when it is running (but this has not been properly tested since Nokia times, so I will not bet that this still works;-).
The instance settings will also get copied into your user configuration and (some) of the sdktool settings can get overridden there by the users. There is a flag in the XML stating which settings are "fixed", the others can be changed.
-
Great that my presentation still helps out people:-)
There is no "global" configuration of stuff, everything is limited to one Qt Creator instance. /usr/share/qtcreator/... is just the default location for a system-wide installed instance of Creator on most Linux distributions.
The sdktool is indeed the best way to register toolchains/qt versions/kits/debuggers/... with one Qt Creator instance. It works by managing some xml files in ../share/qtcreator/QtProject (path is relative to the Qt Creator executable that the sdktool belongs to!).
The ids registered with the sdktool do not get randomized, so you can use it to set up a set of machines with kits that will work across the whole set.
You can symlink/copy the settings to new creator instances though by just placing the ../share/qtcreator/QtProject directory of one instance into the right place for another and it will be picked up by both instances and creator should watch the files and react to them changing when it is running (but this has not been properly tested since Nokia times, so I will not bet that this still works;-).
The instance settings will also get copied into your user configuration and (some) of the sdktool settings can get overridden there by the users. There is a flag in the XML stating which settings are "fixed", the others can be changed.
wrote on 29 Sept 2017, 08:01 last edited by@hunger Thanks for the clarifications and the extra tips how symlink/copy could be an valuable option! I came to the right conclusion as I have understood it :)
Knowing it is tied to one instance of Qt Creator is very valuable information for the future. Then I know that it is necessary to either rerun sdktool for a new instance, or as you suggest, use symlink/copy the files.
So your presentation certainly helped; I'm glad that all these presentations are floating around and also the presentation material.
-
@hskoglund Thanks for the reply, it appears that you are on the right track according to this page. "profiles.xml" and "qtversions.xml" stores information about the kits and versions, but I'm actually having a hard time finding these exact files in my system. What I did find was ".../QtProject/qtcreator/profiles-original.xml" and it contains the information which is related to the auto discovery of kits.
One of the keys in the file is "<value type="bool" key="PE.Profile.AutoDetected">true</value>", I have seen other examples of this file on the Internet with the key set to "false". In my eyes this file is the result from a registered Qt Version, due to the naming of the key. I'll look further into this.
@Pablo-J.-Rogina Thanks for the direction. Looking at the source code was actually an idea I had from the start, but had no clue where to start looking. The file previously mentioned (profiles-original.xml) has a stamp written by the sdktool, so looking further into the sdktool seems to be the right call - if that tool generated the file, it should contain more information how the kits are actually discovered.