On 11.12.2020 12:42, Steve Lhomme wrote:
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.
Ideally, yes. Some of those require fixes on widl side.
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.
I agree and that's how it was meant to be. The history did not go the
way I liked and a number of commits conflicting with upstream was
committed to mingw-w64, making the whole automation unreliable and
preventing widl syncs for quite a while. Resynchronizing those things
would be great. I'm currently doing that to IDLs imported from Wine when
I update them. For non-imported IDLs, I occasionally go through them (I
just pushed such an update), but it needs a lot of manual skipping for
things that don't re-generate correctly. I would be happy to do that to
all IDLs on each widl update once we solve those problems.
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 ?
widl is meant to be midl replacement, so all those futures are welcome.
It lives in Wine tree and has a few Wine-specific features, but it's
meant to be a generic IDL compiler. It also already contains a number of
commits that were really motivated by mingw-w64, not Wine needs.
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.
See Rémi's patches, they implement all mentioned features:
https://github.com/wine-staging/wine-staging/tree/master/patches/widl-winrt-support
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.
I think that we want to get them right at the cost of compatibility with
current headers.
Thanks,
Jacek
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
