I really like the midl.exe idea, as it seems simple to integrate and use with the existing tools.
Thanks, Bernhard
Am Mi., 6. Juli 2022 um 11:48 Uhr schrieb Rémi Bernon rbernon@codeweavers.com:
On 6/15/22 17:20, Bernhard Kölbl wrote:
Hey everyone,
during the course of implementing WinRT / UWP stuff, I regularly come across missing IDL 3.0 features in our Widl compiler. Unfortunately, Widl's code seems to have grown in a rater unpleasant direction and is sometimes a real burden to understand and maintain. I think some refactoring to its code would be very well fitting and make things a lot easier for everyone, but refactoring can also bring breakage and makes tracking down errors with Git harder. Additionally, as the code is already not that small, errors have an easy way to slip in without noticing. So to me, the ideal solution seems to add a testing system to the compiler, like most of Wine's components already have.
Rémi and I already outlined some ideas:
- Port the Winetest system to Unix programs
- Make a libwidl or Widl.exe and test against that with our current test system
- Add the tests into Widl itself as callable parameter
What do you think is the best solution? Getting some suggestions would be great. :)
Thanks, Bernhard
Hi, I thought a bit more about this topic.
What we currently have, from the use of IDLs in Wine, as well as from the existing tests, are checks that validate that WIDL output is ABI compatible with MIDL output, but not really source compatible.
What we additionally need in order to make WIDL more robust and changes easier to review, are tests which:
- Compare what MIDL supports in term of syntax to what we do, to check
whether WIDL parsing changes are correct and required.
- Compare what MIDL generates from a given IDL to what we do, to check
whether WIDL code generation changes are correct.
In order to do that I think we actually have to write tests against native MIDL.
I think 1) is the most critical part, and it's actually the easiest. We can simply write some IDL snippets and run them through MIDL, checking its success or failure, and do the same with WIDL.
For 2), it's a bit more tricky, but I think with a bit of post-processing and string matching it should be possible to check whether the generated files have the expected constructs.
I've made a POC implementation of such tests for 1), in the attached patches. They introduces a new builtin midl.exe, that could ultimately support the same command-line options as MIDL and act as a drop-in replacement, as well as associated tests which require the Windows SDKs to be installed to find native midl.exe to run against.
(I'm only not sure that the use of PARENTSRC to share sources between tools/widl and the new programs/midl is the best way to do it.)
Cheers,
Rémi Bernon rbernon@codeweavers.com