Add support for the Meson build system#495
Conversation
It's either defined or undefined, don't rely on implicit 0 value if it's not defined, this will cause compiler warnings and is a bit crufty.
Modify aes_calc to optionally accept the expected ciphertext as a third argument, so it can error with a non-0 exit code if the calculated ciphertext doesn't match the expected ciphertext. This makes our test setup with meson much easier, as we don't need to parse and compare the output of the test binary. The test is now self-sufficient.
Everywhere else we use `#ifdef`, but here we use `#if`. This causes a build error when using `#define CPU_RISC` like the meson build files do.
d42306b to
717e33d
Compare
|
Hi, I have nothing really against including meson besides the potential maintenance over head. There has been no real discussion on replacing autotools and the current cmake support was seen both as a way to replace hard coded windows project files and to provide a "cross platform" solution to reduce maintenance. If this was to be accepted and you would like to maintain some hope that it does not get broken then I would suggest adding at least a standard linux build to the travis build file. |
|
Thanks for looking at this @pabuhler :) Sorry for not being clear, my intention is not to advocate for Meson to replace any of the build systems used by libsrtp. I'm an outsider to the project after all. As for maintenance overhead, I'd be happy to maintain these build files. I can add a I'll also add some Travis CI builds, thanks for the suggestion! |
|
A datapoint in favour of the idea that this would help more than one project is that there's also a set of meson build files in Meson's WrapDB (code: https://github.com/mesonbuild/libsrtp2/tree/2.2.0) written independently by @xhaakon. @xhaakon would you also like to be in CODEOWNERS for the meson build files in libsrtp if this is merged? |
e8b24b2 to
017fd71
Compare
c2e1adf to
ada6e8f
Compare
I've implemented Meson counterparts for all CI build jobs, and I added a new one specifically for testing the build on WinRT/UWP too. Tests seem to be passing everywhere they could be run. CI now takes ~1-2min more than it used to because the big-endian mips test is the bottleneck and we run tests using Meson there too now. |
|
@pabuhler I can warmly recommend Meson! It makes everything hard and clunky about cross-platform development easy and lean. |
|
@nirbheek thanks for adding the builds to travis, that would have taken me a bit of time to figure out. I think my position has not changed, this is fine for me as long as there is not to much maintenance and if that becomes an issue we can just bin it later. Will wait abit to see if any other people have comments. |
|
@tp-m pointed out to me that it would be good to add a The |
Nothing against that, feel free to add me. |
To get output when the check is run: Checking if "inline keyword check" compiles: YES
Ensure that the meson project version matches the release project version when `make distribution` is run to make a release. Also update the meson version to the correct one: 2.4.0
Run tests under valgrind by calling: meson test --setup=valgrind -C builddir Pass -v / --verbose to see test output while tests are running
We need to include crtdefs.h for the definition of size_t. See: https://docs.microsoft.com/en-us/cpp/c-runtime-library/standard-types Add CI so this doesn't break again.
fcf3cf6 to
e09fbfa
Compare
Done, thanks! Also fixed a build failure on msvc-32-bit and added CI for windows UWP arm64. Edit: CI has passed, but it's not showing status on the PR for some reason. |
8cf9b69 to
32d4d31
Compare
For some reason, pip3 is now trying to build ninja instead of installing the prebuilt binary. Try choco instead.
32d4d31 to
bfde963
Compare
root: deprecated key sudo (The key `sudo` has no effect anymore.) jobs.include: deprecated key sudo (The key `sudo` has no effect anymore.)
|
Gentle poke :) |
|
@nirbheek , sorry for the delay, have been out of the office for a few weeks. Will follow up now. |
|
@nirbheek for me supporting meson seams non trivial as with all build systems there is lots to learn and when adapting to an existing projects there are always special case handling that require even more work. So we can see how this goes and if it does not cause to much work then great but if it becomes a problem we will have to review it. |
|
Thanks a lot for merging this! I'm also happy to help out if there are any issues related to the Meson build, or with keeping it up to date. |
|
Many thanks for merging this 😄 I hope it works out for all of us. Please poke me when you have questions. Either on GitHub, or on FreeNode ( |
Add support for the Meson build system
Hi! I'm a GStreamer developer, and for the same reasons as OpenH264, we've written Meson build files for libsrtp. We use libsrtp in gstreamer for WebRTC DTLS.
The Meson build system is being adopted by projects such as GNOME, GTK, Mesa, GStreamer, etc. I am not sure if such a pull request is welcome, but it would be amazing if you could consider merging this :)
These Meson build files have feature-parity with the Autoconf/Make build files, the Visual Studio solution, and the CMake build files. They are also simpler, faster, and support all target platforms supported by libsrtp (that I know of). The following have been tested:
Linux, macOS, Windows (MinGW), Windows (MSVC), Windows (UWP/WinRT), Cross-Android (all arches), Cross-iOS (all arches), Cross-Linux, Cross-Windows (MinGW).
Meson supports a superset of the currently-supported target platforms, and no platform-specific code should be needed for those, so this also improves cross-platform support.
The build outputs should be ABI-compatible with the outputs by Autoconf, but this has not been verified in detail.
I've also updated the README, and (pasted from there) the steps to try this out are: