Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

ci/mingw: run meson tests #14207

Merged
merged 10 commits into from
Jun 3, 2024
Merged

ci/mingw: run meson tests #14207

merged 10 commits into from
Jun 3, 2024

Conversation

kasper93
Copy link
Contributor

No description provided.

@kasper93 kasper93 requested a review from sfan5 May 21, 2024 23:40
Copy link

github-actions bot commented May 21, 2024

Download the artifacts for this pull request:

Windows
macOS

@Dudemanguy
Copy link
Member

Dudemanguy commented May 22, 2024

By getting rid of subprocesses, you could simplify the meson.build files a lot if you want to. Wouldn't need subprocess_source and some other stuff likely.

@kasper93 kasper93 force-pushed the ci_mingw_test branch 2 times, most recently from 70f2bd3 to 178af33 Compare May 22, 2024 01:50
@kasper93
Copy link
Contributor Author

kasper93 commented May 22, 2024

By getting rid of subprocesses, you could simplify the meson.build files a lot if you want to. Wouldn't need subprocess_source and some other stuff likely.

Removed what I've seen not needed.

.github/workflows/build.yml Show resolved Hide resolved
@@ -141,7 +148,7 @@ _ffmpeg () {
--pkg-config=pkg-config --target-os=mingw32
--enable-cross-compile --cross-prefix=$TARGET- --arch=${TARGET%%-*}
--cc="$CC" --cxx="$CXX" $commonflags
--disable-{doc,programs,muxers,encoders}
--disable-{doc,programs}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather only enable one relevant muxer or encoder for the tests (as on the line below)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if user wants to use different format? What is the gain to exclude some of them?

Copy link
Contributor

@na-na-hi na-na-hi May 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most important encoders like x264/x265 aren't ffmpeg built-in anyway, so the users likely still won't get what they want. At this point most built-in encoders are unnecessary bloat.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But what is the gain of excluding what is available?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lower compile times.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see no significant difference. In cached state it is 4s difference, clean build was also not visibly slower, but I can test that to confirm.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This excludes more than 200 files so it should definitely make a difference uncached.

Copy link
Contributor Author

@kasper93 kasper93 May 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Execution times of Build libraries step:

master #14207
i386 | cached 210 s 170 s 80 %
i386 | clean 976 s 1026 s 105 %
x86_64 | cached 262 s 247 s 94 %
x86_64 | clean 1083 s 1162 s 107 %

It is slower, but the difference in my opinion is not significant enough to making some arbitrary list of enabled/disabled muxers. Note that we almost never do full rebuild, I needed to manually remove cache from my fork to test that.

Tested on CI with the following builds:
https://github.com/mpv-player/mpv/actions/runs/9191373753/job/25277639660
https://github.com/mpv-player/mpv/actions/runs/9183181995/job/25253412400
https://github.com/kasper93/mpv/actions/runs/9192050397/job/25279896478
https://github.com/kasper93/mpv/actions/runs/9192086594/job/25279911198

Copy link
Contributor Author

@kasper93 kasper93 May 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most important encoders like x264/x265 aren't ffmpeg built-in anyway

At least you could save png/jpg screenshot... or something like that.

test/libmpv_encode.c Outdated Show resolved Hide resolved
test/paths.c Show resolved Hide resolved
test/test_utils.c Outdated Show resolved Hide resolved
mktemp is good enough for this test purposes and also tests if libmpv is
able to create a file that doesn't exist.
Helps with testing during cross-compilation and avoids external
dependency.

Output maybe is not that nice, but this output in our tests is not
useful anyway. We know if it changes it is beacuse one of the dependency
version changed.
If pathcch is not available paths are not normalized on Windows.

Fixes tests on ancient mingw.
Allows running complied binaries on build machine.
Copy link
Member

@Dudemanguy Dudemanguy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the meson simplifications.

@kasper93
Copy link
Contributor Author

kasper93 commented Jun 3, 2024

No more comments for a week, let's merge this. Can be improved if needed.

@kasper93 kasper93 merged commit 0c716e7 into mpv-player:master Jun 3, 2024
18 checks passed
@kasper93 kasper93 deleted the ci_mingw_test branch June 3, 2024 17:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants