[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