[PATCH resend 1/5] mf/tests: Simplify handling of broken Win7 results.

Rémi Bernon rbernon at codeweavers.com
Tue Apr 19 10:52:00 CDT 2022


On 4/19/22 17:36, Zebediah Figura wrote:
> On 4/19/22 08:56, Rémi Bernon wrote:
>> I now think that, though there's no guarantee the modules won't change,
>> the transform / dmo classes and their tests should perhaps better live
>> in the same modules where native has them. It is in theory possible that
>> some applications load them and instantiate the classes directly, and I
>> don't think it is likely that windows will remove these modules.
> 
> Maybe, although Windows has moved or deleted codecs in the past. (And I 
> expect that if an application really does try to manually instantiate a 
> class, it'll be easy to debug and may not even mean moving the entire 
> implementation out of winegstreamer.)
> 
> Beyond that, though, why should the tests live in the same directory as 
> the implementation? At best this helps make sure that tests are 
> automatically run by the testbot, but as the person ensuring that all 
> tests are manually run, I don't particularly see a need to change this 
> (e.g. I'm still going to need to run tests manually anyway.) If we 
> really care about this, we should come up with a solution that'll allow 
> us to automatically run tests in other places where we have strong 
> inter-module dependencies.
> 
>>
>> The main blocker for that is winegstreamer being a dll and the classes
>> being registered in it. Perhaps it should be a static lib instead, or
>> expose the unixlib interface as its PE entry points.
> 
> I don't think we can make winegstreamer a static library, but moving one 
> or more frontends out of it is possible. It doesn't seem necessary yet, 
> though.
> 


I don't know, I'm trying to understand why these patches often stall and 
to figure a way to make it go smoother.

I'm not pretending the tests are all good and should be accepted right 
away but I hope they aren't completely nonsensical either. I still have 
plenty of tests to add, and I'm happy to maintain them if it's a burden 
for the modules maintainers.

-- 
Rémi Bernon <rbernon at codeweavers.com>



More information about the wine-devel mailing list