On 28/02/2025 12:26, Jörg Bornemann wrote:
On 2/21/25 4:40 PM, Nicolas Arnaud-Cormos via Development wrote:
I think a better solution would be to have the natvis files embedded
into the pdb on Windows, for multiple reasons:
- no need to set a natvis file on VSCode or VS for those not using
the extension,
- in case of internal changes for the Qt classes, we could adapt the
file and ty it to a specific Qt version,
- slightly more visible place for people to contribute.
Embedding into the DLLs doesn't cut it, unfortunately, as Kai already
pointed out. But we could add CMake code that embeds the natvis files
in the user's binaries (as Marcus already wrote).
Here be dragons!
I'm not an expert, but I suspect your natvis license prevent from
integrating into any customer binaries using the free version of Qt...
or at least it's a very gray area.
Having the natvis files directly in Qt has only one disadvantage: we
can't add the natvis files to already released Qt versions.
Right, probably have more sense to have a separate global repo for
natvis, and have the Qt installer propose an update for all already
installed Qt versions. Easy to say, I know...
Another solution, at least better than right now, would be to have a
repo for the natvis, that could be used by both the VsTools extension
and the VSCode extension.
Not my best choice, but at least it will give a better visibility to
it and reduce the pain to contributions.
This was considered in the beginning of the VS Code Extension's
development, and we even have the (unused) repo in place:
https://code.qt.io/cgit/qt-labs/vs-debugtools.git/
We never continued with this, because we reconsidered and wanted to
add the natvis files to the Qt repositories instead. Here's a deferred
change that does this:
https://codereview.qt-project.org/c/qt/qtbase/+/560899
What does deferred mean here?
In my book, it usually means "nice to have when someone will have
time", which is basically never ;)
At the end of the day, the change tried too much:
- natvis files are installed to lib (finally!)
- -qtnamespace is automatically replaced (no more search & replace!)
- the natvis files are split per module (maybe not needed?)
- an autotest was added (too ambitious?)
Esp. the last point was essentially the blocker. We're using cdb here
to test the debugging visualizers, and - as it turns out - cdb uses
yet another natvis dialect than what VS understands. We really wanted
to have an autotest since we cannot change released Qt versions...
Interesting, I was wondering if it was possible to do automatic tests of
natvis files... guess it's probably very difficult without instrumenting
Visual Studio itself.
We can probably improve things already by ditching the testing
attempt, but keep in mind that we're dealing with three different
natvis dialects:
- full blown VS natvis
- reduced (or just old?) natvis of cdb
- severely reduced natvis subset of cppdbg for VS Code
The cdb one isn't that important, unless Qt Creator starts to use that.
I would ditch both cdb and cppdbg and focus only on Visual Studio and
cppvsdbg.
Thanks for the answer, very interesting.
Cheers,
Nicolas
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
