On 2020-12-13 11:43, Jacek Caban wrote:
On 11.12.2020 12:42, Steve Lhomme wrote:
On 2020-12-11 1:02, Jacek Caban wrote:
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.
I think I got almost everything building.
There's wincrypt.idl which is odd because it depends on wincrypt.h,
which is generates...
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
Ah this is great. It seems to have everything needed. I'll give it a try.
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.
OK. There is a patch that adds generation of defines to use the old
names if the user defines "WIDL_USING_WINDOWS_FOO_IFOO". That may be
enough to keep compatibility with older code (or those who want to use C
without the extra long names).
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
