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
