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@xxxxxxxxx> wrote:
Hi,
On 26/02/2021 16.02, Hossein Noorikhah wrote:
> On Fri, Feb 26, 2021 at 3:46 PM Michael Weghorn <m.weghorn@xxxxxxxxx> 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
_______________________________________________ LibreOffice mailing list LibreOffice@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/libreoffice
