<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Hi,</div><div class="gmail_default" style="font-family:tahoma,sans-serif">You're right. Using .pro files for different directories is better than a single file.<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">A single .pro file has problems caused from the overlap of include folders, in situations where things like this:</div><div class="gmail_default" style="font-family:tahoma,sans-serif">#include <a/b></div><div class="gmail_default" style="font-family:tahoma,sans-serif">and</div><div class="gmail_default" style="font-family:tahoma,sans-serif">#include <a/c></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Performance can also be an issue.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">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.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Thanks,</div><div class="gmail_default" style="font-family:tahoma,sans-serif">Hossein</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 1, 2021 at 11:50 AM Michael Weghorn <<a href="mailto:m.weghorn@posteo.de">m.weghorn@posteo.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 26/02/2021 16.02, Hossein Noorikhah wrote:<br>
> On Fri, Feb 26, 2021 at 3:46 PM Michael Weghorn <<a href="mailto:m.weghorn@posteo.de" target="_blank">m.weghorn@posteo.de</a>> wrote:<br>
>><br>
>><br>
>> On 26/02/2021 13.05, Hossein Noorikhah wrote:<br>
>>> workdir/GbuildToJson/Library/libvcllo.so is blank. But VS Code<br>
>>> project has all the .cxx and .h files.<br>
>><br>
>> Looking at 'vs-code-template.code-workspace', it seems to just include<br>
>> the whole source tree as a directory, so I suspect that there's no<br>
>> problem since simply all header and source files in there will be included:<br>
> <br>
> So, why not do the same for the Qt Creator? It can cause no harm, since<br>
> the build system is separate. Finding source files, adding them to a single<br>
> <a href="http://lo.pro" rel="noreferrer" target="_blank">lo.pro</a> file, and that's all. What do you think about such an approach?<br>
> Maybe other useful file types can also be included.<br>
> <br>
> $ find -iname "*.cxx" -o -iname "*.hxx"|wc<br>
>    21243   21243  901070<br>
<br>
Different modules can be built with different parameters (like defines, <br>
include paths, compiler/linker flags), s.a. the .pro files. Mixing all <br>
of them together and setting all of them for all source files wouldn't <br>
really be "correct" in a strict sense. If I remember correctly, even <br>
with the current approach, the flags for all libraries/executables in <br>
one subdirectory are already "merged together". As long as there are no <br>
conflicting options, this should be no problem in practice, though, and <br>
*might* be no problem when doing everything it similarly in the <br>
top-level <a href="http://lo.pro" rel="noreferrer" target="_blank">lo.pro</a> either.<br>
<br>
While those parameters in the .pro files are not relevant for the actual <br>
build (since Qt Creator just calls 'make' anyway and that one does not <br>
rely on what is set in the .pro files), Qt Creator uses the information <br>
from the .pro files for its Clang Code Model, which provides e.g. <br>
autocompletion, code navigation, displaying compiler warnings and errors.<br>
<br>
So I *guess* (but haven't tried) that just adding all the sources and <br>
headers to <a href="http://lo.pro" rel="noreferrer" target="_blank">lo.pro</a> wouldn't give you a nice setup with the <br>
'--enable-mergelibs' autogen option set either, since the code model <br>
wouldn't work properly due to missing parameters (assuming that they are <br>
not properly propagated to workdir/GbuildToJson, as it seems).<br>
<br>
<br>
Conceptually, it would probably be "most correct" from a build system <br>
perspective to have a separate .pro file for each library/executable <br>
(e.g. to generate a single .pro file for each of the <br>
'workdir/GbuildToJson/Library/libvclplug_*' files instead of merging <br>
them into 'vcl/<a href="http://vcl.pro" rel="noreferrer" target="_blank">vcl.pro</a>').<br>
<br>
<br>
However, I'd say it makes sense to be pragmatic, so IMHO, it's a <br>
question of what the practical advantages/disadvantages of changing the <br>
current approach would be.<br>
Since the current approach is working fine for me (and it has been like <br>
that since I've been using it; I'm not the original author of <br>
qtcreator-ide-integration), I didn't see a real "need" to further <br>
evaluate changing the way of how this aspect is handled so far.<br>
If there are practical advantages of changing that (to either just have <br>
a single top-level .pro file or further split the current ones), I see <br>
no reason not to do so.<br>
<br>
Two more thoughts on the current handling came to my mind:<br>
<br>
1) You can also just build a single module by e.g. right-clicking on the <br>
"vcl" directory in Qt Creator and selecting "build vcl".). It's also <br>
possible to just load e.g. <a href="http://vcl.pro" rel="noreferrer" target="_blank">vcl.pro</a> as a project instead of the whole <br>
<a href="http://lo.pro" rel="noreferrer" target="_blank">lo.pro</a>. I've never really used that myself, since loading the full <br>
project is reasonably fast and I build from command line most times <br>
anyway, but it might be something to keep in mind when evaluating what <br>
pros/cons different approaches have.<br>
<br>
2) With the current approach, you just see those source files in the <br>
project view that are actually compiled (e.g. don't see Windows-specific <br>
files when building on Linux). That can be seen as either an advantage <br>
or a disadvantage.<br>
<br>
<br>
Regards,<br>
Michael<br>
</blockquote></div>