`meson` build is broken in 3.0.1

[mmomtchev]

Certainly after moving around the directories, but the new configuration files are also missing from meson.

[mmomtchev]

I am trying to fix the meson build in 3.0.1, but I do not understand the new AVCPP_... version macros, why are these needed, why not simply use the ffmpeg-defined macros?

[h4tr3d]

@mmomtchev

I do not understand the new AVCPP_... version macros, why are these needed, why not simply use the ffmpeg-defined macros?

It is possible to build binary part of the AvCpp with one version of the FFmpeg libs (old one, for example) and use with new one across same Major version. But if header opens new functionality according new Minor version it implementation may be lacked in the binary code. So, I fix a versions of the FFmpeg libs that used for the binaries build. Same motivation for the used C++ standard. As an additional, same mechanism are used make libavformat, libavdevice and libavfilter optional.

It is not a problem, when AvCpp used as submodule or via FetchContent but can be an issue when distributed via package managers: for example, ArchLinux time to time has a time lag between some library update and all dependent code rebuild. AUR also introduce same lag.

BTW, if you fix meson build, could you please also turn it on in the CI:

avcpp/.github/workflows/cmake-ci.yml

Line 23 in fdf5b3f

skip_meson: [true]

(meson test building now used for the macos only) and update README.md Meson section: drop Caution and fill actual information, if any.

Thanks for contributing!

[mmomtchev]

If you include the ffmpeg headers when building, the value of the macro won't change at runtime.

#define LIBAVCODEC_VERSION_MAJOR  61

this becomes 61 as hard-coded value in the avcpp.a or avcpp.so. If the dynamic linker loads a newer version of a dynamic libavcodec.so with its own LIBAVCODEC_VERSION_MAJOR, the value in avcpp will still be 61.

[mmomtchev]

Also, I wonder if it is not possible to replace the AVCPP_CXX_STANDARD with the standard __cplusplus macro, it is part of the C++ specification so all compilers must define it the same way - unless the setting is needed in the makefile itself. Because CMake seems to handle this, but with meson I have to also handle the gnu++20 setting separately. For once MSVC is the one compiler that is not peculiar.

[h4tr3d]

61 as hard-coded value in the avcpp.a or avcpp.so. If the dynamic linker loads a newer version of a dynamic libavcodec.so with its own LIBAVCODEC_VERSION_MAJOR, the value in avcpp will still be 61.

You are right! But if LIBAVCODEC_VERSION_MAJOR used in the avcpp/codec.h (header!) it may be changed on the next application build: new functionality in the header, but old in the libavcpp.a/so.

Same for __cplusplus. If header used with newer standard, but pre-compiled binary with old, header can open functionality, that lack in the binary.

Again, it is not a problem, when AvCpp uses in source mode, but it is an issue when AvCpp used in pre-compiled way. In such case constant must be fixed on the configuration step to keep consistency between headers and binary library.