[Development] [Windows] State of the Qt6 natvis file

[Nicolas Arnaud-Cormos]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20250228/0b76d5ec/attachment.htm>