On Tue Aug 23 11:06:56 2022 +0000, Jacek Caban wrote:
widl can already be used as a drop-in midl replacement in some cases, for example when building Firefox (and we recently started using it for Gecko). It works because I fixed compatibility in required aspects, see commits like 1db0ad9798f, 511b50e7bf, fc761cb9352d. I don't see why we can't support more options like that. If we run into a backward compatibility problem, we may always add a way to be more explicit about midl/widl compatibility mode. Do you have some specific problems in mind?
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?