Add meson build system - #471
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 (so, muon 0.6.0 and over work fine). muon is usefull for distro that doesn't ship meson 1.3.0 or newer. It allow to build on any distro where gcc support c++11 (because muon simply require gcc 4.5 and c++11 was added in gcc 4.8.1). It is fairly simple to build muon from scratch. See the bootstraping instruction here. |
084a03d to
605ed85
Compare
|
I just fixed the conflict due to 0fa01d0 |
|
Don't remove the the msvc build. It's very useful for testing and debugging and people who want to contribute easily. |
|
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. |
What I was implying is: does it still make sense to support this platform?
Well, maybe it's time to change! |
|
@dwbuiten Do you have any interest in this PR? |
|
Why still need Cygwin and MSYS if everything can be installed/builded without it? |
…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
```
Since 2026-03-15, MINGW64 is deprecated: https://www.msys2.org/news/#2026-03-15-deprecating-the-mingw64-environment
MSYS2 is still needed because it provides gcc and clang. GCC and Clang often produce faster and more optimized binaries than MSVC. |
|
Just out of curiosity, why don't you simply model this after the bestsource build system/CI? After my latest changes it builds everything with clang and on windows msvc as well. In addition to that it attaches both clang and msvc binaries for windows on release automatically. This has clogged my github notifications for long enough. |
What do you my by "bestsource build system"? For the CI, from what I can see, bestsource has
ffms2 still doesn't support wheels, so except I believe it is a good practice to compile code on many platform as possible. PS: Note that I will add python wheels support to ffms2 in another PR. I am trying first to simply replace autotools with meson first. |
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.