On Tue Aug 23 11:19:29 2022 +0000, R��mi Bernon wrote:
I don't have anything specific in mind, just forward thinking about it as it doesn't look like widl was meant to be command-line compatible (it has some specific options and different names for some that are in midl). In any case, I don't mind trying to make widl more compatible, then I don't think it makes much difference for the matter of testing it. For that, I think it makes sense to have a builtin exe version of widl, named either midl.exe or widl.exe, because that's how all the Wine conformance tests are done. The widl tests are conformance tests in the exact same way as the other Wine tests are: we want to compare native behavior with our own implementation. I don't think it makes any sense to have another testing mechanism just for widl. Then, the question becomes how do we build both a tool used for building Wine, and a PE version of it for testing purposes. I have a simple implementation for that, sharing mostly everything from tools/widl to program/midl with a PARENTSRC and a few small changes to the code. Maybe that's better than trying to share less first, and incrementally add features to the builtin?
Let me rephrase my previous question: what value does all that bring? Is there anything other than testing parser failures?