Replies: 6 comments 9 replies
-
|
Thanks for the suggestion. I think this is worth discussing. IMO there would be more downsides than benefit to switching to Meson. CMake's syntax is clunky and the documentation persistently sucks, but it's nice to use and package... so long as you don't abuse it into a tangled mess that you don't even test if it actually works like Audacity. I'm working to bypass Audacity's dependency finding hackjob in #228. I think that is the most maintainable path forward. Completely switching build systems would make it difficult to merge big changes from Audacity in the future. Also, Meson has no integrated tooling for macOS and Windows packaging. CMake does, it is already set up, and it works. Do not underestimate how much work this is to set up even with CPack doing a lot of the work. Meson is implemented in Python, which is quite problematic for packaging. C++ programs should not need to bring in Python with its whole dependency graph just to build. That is a substantial complication for bootstrapability. The Guix developers have been making good progress on that large, complex problem; let's not make it worse. Pinging @matthiasbeyer on this. |
Beta Was this translation helpful? Give feedback.
-
|
@Be-ing I know of a couple of such applications:
Additionally, many ElementaryOS/GNOME programs use Meson, as well as Pitivi and Akira, and I have had partial success in compiling them on Mac/Windows. However, calling them "cross-platform" is bit of a stretch. |
Beta Was this translation helpful? Give feedback.
-
Well, tbh the idea of "managing dependencies" feels very much like an anti-pattern. Dependencies should be managed by higher level tools like Conan or vcpkg, or package managers like homebrew or msys2 pacman. Install with that first, then run your build system pointed to there. In that respect, meson shouldn't be particularly unusual. As I said, meson officially supports picking up any dependency available in cmake, by running a small CMakeLists.txt which searches for that dependency and then uses cmake's tracing API to get the build flags and libraries. It generally works quite well, and behaves just like using pkg-config. For any dependency which uses meson, it's even easier. You can add a "wrap" ini file pointing to the tarball download location of e.g. gtk3 and if meson cannot detect the gtk dependency via pkg-config or cmake it will download the source code, checksum it, and build a private copy for you. There is also the meson wrapdb, containing meson.build files for various libraries that don't already build using meson, so that you can use them as subprojects. Tenacity may be interested in the wraps for e.g. vorbis, ogg, flac, expat, lame... End result: if all your dependencies are wrapped, then users can download the tenacity source code on any OS, build it without even trying to figure out dependencies, and it "just works". If done on Linux, many dependencies may already be available on the system, and that "just works" too. |
Beta Was this translation helpful? Give feedback.
-
|
Meson has a core option to specify that you want to force all dependencies to use wraps if a wrap exists, or alternatively, specify a list of dependencies which you prefer wraps for. You can also specify to build a wrapped subproject as a static library to simplify linking and distribution as a single binary. (This does not help for dependencies like qt or gtk which don't really support static linking well, because "that's complicated to do for plugins".) |
Beta Was this translation helpful? Give feedback.
-
|
For the record -- I am absolutely biased in favor of meson, so take my words with a grain of salt and make up your own mind. As a user I liked meson so much I finagled my way into the project and am now one of the meson core maintainers... |
Beta Was this translation helpful? Give feedback.
-
|
That all sounds nice, and if we were starting a new application from scratch I think it would be good to consider Meson more seriously. I've already made good progress cleaning up the CMake build system in #228 so I don't think it would be worthwhile to start over with a completely different build system. Plus the issue with merging future changes from Audacity would still remain. |
Beta Was this translation helpful? Give feedback.
-
|
The 4chan joke fork is trying to switch to Conan. It would be interesting to watch how far it goes. |
Beta Was this translation helpful? Give feedback.
-
|
Feel free to fork Tenacity yourself in order to implement a meson-based build system. In my experience, however, making backward-incompatible changes, especially to something as major as a build system, will not benefit a project. |
Beta Was this translation helpful? Give feedback.
-
|
I would also like to see Tenacity using Meson. The current set up of Audacity is really overbloated and meson would make it much easier. But maybe we should keep being on CMake cause the syncing and rebasing Audacity would make it MUCH easier. The PR you mentioned is from Jul 9, 2018. So we can't simply rebase his changes, as there is much gone in that time. |
Beta Was this translation helpful? Give feedback.
-
|
I agree, switching the build system without need does not help the project. But the currently broken build does not help either. The last changes from Audacity to the build system did not improve this. For Linux, there was a working autotools build before Audacity 3.0. Now, there is this CMake build with all those hacks. The last changes only increased this mess e.g. by adding mandatory Conan so I wouldn't rely on Audacity for this. The current build system looks like it is unnecessarily compilcated to me. So a new Meson based build might be much simpler. If the pull request from @Be-ing succeeds and removes the worst CMake hacks as well as Conan and other external dependencies, I'll totally agree that that build system should not be changed. When bootstrapping this project on Linux, Python and meson are already necessary to build gtk. So I think adding them to Tenacity's dependencies is not a big deal. I don't know about the CMake vs Meson situation for packaging on Windows and MacOS. The last time I did this, I used a plain Makefile which used either GCC or cross compiled with MinGW and copied the results with a small script. If there is a change that this will be accepted, I may try a meson based build for Tenacity when I find some time. In this case, I would start from scratch since the code from audacity/audacity#281 is most likely not usable due to licensing reasons. |
Beta Was this translation helpful? Give feedback.
-
Packaging for both macOS and Windows is not fun. |
Beta Was this translation helpful? Give feedback.
-
|
Here's a rather unusual idea - what about Docker? It's (relatively) easy to setup, and once we have a tenacity docker image we can run it across numerous operating systems to compile Tenacity. However, here are 2 caveats:
|
Beta Was this translation helpful? Give feedback.
-
Since the current CMake build is quite broken and hacky with all those cmake-proxies, it may a good opportunity to switch to meson.
Meson is a fast, feature-rich, multi-platform build system which focuses on usability which is often used as autotools replacement. Things like precompiled headers which required hacks in cmake until a very recent version (3.16) just work out of the box with meson.
The pull request audacity/audacity#281 from Audacity could be an example how a meson build would look like.
What do you think about this?
Beta Was this translation helpful? Give feedback.
All reactions