On 2020-12-11 1:02, Jacek Caban wrote:
Hi Steve,
Hi Jacek,
It's great to see work on getting those IDLs to be in a form that we can
regenerate them again. Thanks!
Yes. For now I call widl manually because it seems that many of the IDLs
currently don't build. Should we fix those as well ? Apart from the
winrt ones they don't use a namespace so should produce more of less the
same thing as before.
There is recently an active (well, except for Wine code freeze) work on
Wine side to improve support for winrt widl mode by Rémi Bernon.
Great news.
Hopefully widl will be able to properly support all those new
constructs. I recently updated widl in mingw-w64 repo to a more recent
upstream version and it already generates those headers differently. I
think this patch will not work with enum handling changes.
I'll have a look. I also noticed the wine code has even more changes.
But IMO the IDLs and the headers in the mingw64 tree should match the
widl in the same tree, IMO.
That's why updating widl should also be paired with running the IDLs
through it again. And why it's important the current tree already builds
properly.
Also, I'm not convinced that we want more new interfaces that require
hacking around widl shortcomings. It would be great to have those fixed
in widl instead. I'd say we should get changes that allow us to
regenerate existing declarations with the new widl, but coordinate with
widl on new additions.
After having to hack my way through the IDLs files I agree. Alhough it
seems there are some lexer in widl that I may not be capabale to update.
But that would definitely be a good goal.
On the other hand, widl seems to be mostly a wine thing and there is no
IDL with namespaces, events, templates, etc. Would changes that have no
use in wine be accepted anyway ?
One thing that should be easy to support is eventadd/eventremove
support. It's just adding a prefix like propget/propput.
Templates are trickier because each variant has its own UUID which is
not defined in the MS doc nor in their IDL files. Luckily just by
implementing them it's possible to get the proper UUID when the code
requests it in QueryInterface(). That means each variant needs to be
explictely declared and given its UUID.
The generated names in MS headers are quite different as well as they
include the number of elements in the template and the full namespace
for each element in the template. Proper templating in widl should
produce similar code so code compiling with MSVC can also compile with
mingw64.
I will have a look at that but make no promise.
What about this particular patch that changes the generated code, making
previous code that compiled with mingw64 unusable. It's my understanding
that this file (and pretty much all the winrt) was added for VLC so
maybe noone else is using it ? The code was not compatible with MSVC
headers but after this patch it should be.
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
