Added some information about Qt Creator IDE integration to the wiki
m.weghorn at posteo.de
Mon Feb 15 11:26:10 UTC 2021
On 12/02/2021 21.53, Hossein Noorikhah wrote:
> I went through the sequence, and nothing has changed. It's a question for
> me: why do we need a fresh Qt Creator profile? In very rare situations, I had to
> clean up this profile. Also, I usually do not re-run ./autogen.sh because I
> didn't have any changes in the libs/configurations, and I only pulled the latest
> master from the git repository. This time, I re-ran autogen.sh again, and again
> nothing has changed.
There's generally no need for a fresh Qt Creator profile. I just did
that to avoid potential side-effects of an existing profile when
double-checking it works for me.
There shouldn't be any need to manually re-run autogen.sh either unless
you change your autogen.input.
> But, now I know what you're doing. I thought that only lo.pro is generated, but
> now I see that lo.pro.user is also being generated. That didn't help me, because
> the used Qt kit was not ok. I saw a manual Qt kit which is used for the
> configuration. It was called 'Replacement for "Desktop"', so I removed it and
> reconfigured the project using the appropriate kit. In this case, I
> had to add the
> previously discussed configurations manually.
Can you try what happens if you use that 'Replacement for "Desktop"' kit
instead? That's what I'm doing and which should contain the settings
from lo.pro.user (i.e. the build and run configurations).
As far as I can see, the *.pro.user contains settings specific to one
kit, and those kits have unique UUIDs, i.e. are different for each
user/profile, which is why that can't be mapped to your existing kit.
> To create a viable solution that lasts even when you re-configure the project, I
> think it is needed to put all the configuration in .pro files, and not in
> .pro.user files, because they can be removed/changed at any time.
I'd generally agree, but currently don't see a way to make this work.
*.pro files are not files for the Qt Creator IDE in the first place, but
for the qmake build system (which is one of the build systems that Qt
The *.pro.user file is used to store user-specific Qt-Creator-specific
settings for a project.
When loading a qmake project (using the .pro file) in Qt Creator, it
tries to automatically derive the corresponding build and run settings,
which is also why you get the "qmake" build step etc. if you just use
the *.pro file and not the *.pro.user one.
That's why the *pro.user file is used to set "proper" build steps and
run configuration for the LO case.
I currently see no way to instead derive those automatically from the
.pro file only.
In other words: The current way that qtcreator IDE integration works is
by generating a fake qmake project (using .pro files) for LibreOffice,
then manually overriding run/build configurations using the .pro.user
files. This is necessary because LO actually uses its own build system
(gbuild), for which there is no native support in Qt Creator.
That's a bit of a hack; things would probably be a bit easier if LO
wasn't using its own build system but one of those natively supported by
Qt Creator (like CMake, qmake or meson (for which there is experimental
Generating the *.pro.user files is actually not ideal and they're not
really meant to be shared, but it seems to be working well for me in
practice when I select the 'Replacement for "Desktop"' kit when
initially loading the project.
In order to directly match an actual kit, one could try to retrieve the
UUID for a valid kit from the settings in the Qt Creator profile and use
that one when generating the *.pro.user files, but that's not ideal
either in my opinion (e.g. one would have to "guess" what kit is the
right one, rely on a specific Qt Creator profile path,...).
I just recently read about *.pro.shared files  which are actually
meant to share project settings. Those might actually be a better way to
handle all of this.
I'll probably take a closer look at some point in time.
> And for the contents of lo.pro, I still get "." as the first
> subdirectory. I have to
> manually change it to "../core".
As mentioned in my previous email, I can take a quick look whether I can
see anything obvious if you upload your generated files somewhere or
send them by email and tell me the paths used in your case (and whether
you use a separate build dir).
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.org
More information about the LibreOffice