Added some information about Qt Creator IDE integration to the wiki

Michael Weghorn m.weghorn at
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 ./ 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 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 either unless 
you change your autogen.input.

> But, now I know what you're doing. I thought that only is generated, but
> now I see that 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 (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 
Creator supports).

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 [1] 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, 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).



> Regards,
> Hossein
> _______________________________________________
> LibreOffice mailing list
> LibreOffice at

More information about the LibreOffice mailing list