Added some information about Qt Creator IDE integration to the wiki

[Michael Weghorn]

Hi,

On 26/02/2021 16.02, Hossein Noorikhah wrote:
> On Fri, Feb 26, 2021 at 3:46 PM Michael Weghorn <m.weghorn at posteo.de> wrote:
>>
>>
>> On 26/02/2021 13.05, Hossein Noorikhah wrote:
>>> workdir/GbuildToJson/Library/libvcllo.so is blank. But VS Code
>>> project has all the .cxx and .h files.
>>
>> Looking at 'vs-code-template.code-workspace', it seems to just include
>> the whole source tree as a directory, so I suspect that there's no
>> problem since simply all header and source files in there will be included:
> 
> So, why not do the same for the Qt Creator? It can cause no harm, since
> the build system is separate. Finding source files, adding them to a single
> lo.pro file, and that's all. What do you think about such an approach?
> Maybe other useful file types can also be included.
> 
> $ find -iname "*.cxx" -o -iname "*.hxx"|wc
>    21243   21243  901070

Different modules can be built with different parameters (like defines, 
include paths, compiler/linker flags), s.a. the .pro files. Mixing all 
of them together and setting all of them for all source files wouldn't 
really be "correct" in a strict sense. If I remember correctly, even 
with the current approach, the flags for all libraries/executables in 
one subdirectory are already "merged together". As long as there are no 
conflicting options, this should be no problem in practice, though, and 
*might* be no problem when doing everything it similarly in the 
top-level lo.pro either.

While those parameters in the .pro files are not relevant for the actual 
build (since Qt Creator just calls 'make' anyway and that one does not 
rely on what is set in the .pro files), Qt Creator uses the information 
from the .pro files for its Clang Code Model, which provides e.g. 
autocompletion, code navigation, displaying compiler warnings and errors.

So I *guess* (but haven't tried) that just adding all the sources and 
headers to lo.pro wouldn't give you a nice setup with the 
'--enable-mergelibs' autogen option set either, since the code model 
wouldn't work properly due to missing parameters (assuming that they are 
not properly propagated to workdir/GbuildToJson, as it seems).


Conceptually, it would probably be "most correct" from a build system 
perspective to have a separate .pro file for each library/executable 
(e.g. to generate a single .pro file for each of the 
'workdir/GbuildToJson/Library/libvclplug_*' files instead of merging 
them into 'vcl/vcl.pro').


However, I'd say it makes sense to be pragmatic, so IMHO, it's a 
question of what the practical advantages/disadvantages of changing the 
current approach would be.
Since the current approach is working fine for me (and it has been like 
that since I've been using it; I'm not the original author of 
qtcreator-ide-integration), I didn't see a real "need" to further 
evaluate changing the way of how this aspect is handled so far.
If there are practical advantages of changing that (to either just have 
a single top-level .pro file or further split the current ones), I see 
no reason not to do so.

Two more thoughts on the current handling came to my mind:

1) You can also just build a single module by e.g. right-clicking on the 
"vcl" directory in Qt Creator and selecting "build vcl".). It's also 
possible to just load e.g. vcl.pro as a project instead of the whole 
lo.pro. I've never really used that myself, since loading the full 
project is reasonably fast and I build from command line most times 
anyway, but it might be something to keep in mind when evaluating what 
pros/cons different approaches have.

2) With the current approach, you just see those source files in the 
project view that are actually compiled (e.g. don't see Windows-specific 
files when building on Linux). That can be seen as either an advantage 
or a disadvantage.


Regards,
Michael