Conversation
100349f to
8dcda06
Compare
|
If this covers 100% of the functionality of |
3794c8f to
675daae
Compare
Yes, it does. I also decided to add a small test on top of introducing meson. PS: Note that you can also use muon to build the project, but you need at least to use a version that include this commit due to a bug. |
084a03d to
605ed85
Compare
|
I just fixed the conflict due to 0fa01d0 |
…lease The workflow "Release Windows artifacts" will be runned when we create a new github release. It will automatically create the .7z file containing the x86 + x64 build and add it to the release.
We cannot use ffmpeg oackage available on cygwin repo because the build doesn't contain a HEVC decoder. See: https://cygwin.com/pipermail/cygwin/2026-March/259560.html
…vailable to build the project
This allow to fix these errors when compiling on cygwin:
```
../src/vapoursynth/VSHelper4.h:76:9: error: there are no arguments to 'posix_memalign' that depend on a template parameter, so a declaration of 'posix_memalign' must be available [-fpermissive]
76 | if (posix_memalign(&tmp, alignment, size))
| ^~~~~~~~~~~~~~
../src/index/ffmsindex.cpp:122:20: error: 'strdup' was not declared in this scope; did you mean 'strcmp'?
122 | pair.Key = strdup(en->key);
| ^~~~~~
| strcmp
```
The goal is to catch issue like this one: FFMS#472 (comment)
Fix these errors reported by clang:
```
FAILED: [code=1] test/c99_header.p/test.c.o
clang -Itest/c99_header.p -Itest -I../test -I../include -fdiagnostics-color=always -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Wpedantic -Werror -std=c99 -O3 -pedantic -MD -MQ test/c99_header.p/test.c.o -MF test/c99_header.p/test.c.o.d -o test/c99_header.p/test.c.o -c ../test/test.c
In file included from ../test/test.c:2:
../include/ffms.h:436:30: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
436 | FFMS_API(int) FFMS_GetVersion();
| ^
| void
../include/ffms.h:437:31: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
437 | FFMS_API(int) FFMS_GetLogLevel();
| ^
| void
```
|
Don't remove the the msvc build. It's very useful for testing and debugging and people who want to contribute easily. |
|
| - name: Setup MSYS2 (MINGW64) | ||
| if: matrix.windows_env == 'msys2' | ||
| uses: msys2/setup-msys2@v2 | ||
| with: | ||
| msystem: MINGW64 | ||
| install: >- | ||
| mingw-w64-x86_64-ca-certificates | ||
| mingw-w64-x86_64-ffmpeg | ||
| mingw-w64-x86_64-meson | ||
| mingw-w64-x86_64-toolchain |
There was a problem hiding this comment.
MINGW64 is deprecated. At least, it should be UCRT64 but using CLANG64 is probably the way to go if that works fine.
I don't use visual studio, but the option |
Simply, to be sure we still support this platform.
Because we don't use it in the master branch. |
Since 2026-03-15, MINGW64 is deprecated: https://www.msys2.org/news/#2026-03-15-deprecating-the-mingw64-environment
What I was implying is: does it still make sense to support this platform?
Well, maybe it's time to change! |
This is a second attempt to add meson build system support (#338) since I believe meson is now a bit more mature. It is still pretty new compare to autotools, but as some benefits (ex: easy cross-compilation, IDE support, support MSVC out of the box).
I did it just for fun, but since it allow to build the unit tests with MSVC, I thought it might be a good idea to share it.
I also tested all the possibilities (ffmpeg->shared + ffms2->shared build, ffmpeg->static+ ffms2->shared build, etc...) in this PR to be sure to cover as many use case as possible.
The second commit is a "bonus", but can be useful since, in the last release, I believe you forgot to include the x86 build (see issue #470). If you want, I can add a arm64 build since windows arm is slowly getting a bit more common.
Also, if you want me to add renovate to automatically update
subprojects/AviSynth+.wrapversion, tell me.