Added some information about Qt Creator IDE integration to the wiki

[Hossein Noorikhah]

Hi,
You're right. Using .pro files for different directories is better than a
single file.

A single .pro file has problems caused from the overlap of include folders,
in situations where things like this:
#include <a/b>
and
#include <a/c>
exist in two different files, in which the first "a" folder is different
from the second "a", so that only one of these includes work.

Performance can also be an issue.

I cleaned up everything, built the project and re-generated the Qt Creator
project files, and now everything seems to be fine. I am happy with the
current qt integration, but I will try creating a per folder .pro files
from all cxx/hxx files.

Thanks,
Hossein

On Mon, Mar 1, 2021 at 11:50 AM Michael Weghorn <m.weghorn at posteo.de> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20210301/721c4c30/attachment.htm>