Add meson build

[amibranch]

Is your feature request related to a problem? Please describe.

This issue is not a feature request, but rather a collection and proposal to rework some parts of the build-system and about answering the following general question:
Will rizin/cutter use meson-build consistently?

I started to create the changes to rizin, cutter and rz-ghidra project as I wanted to build all three projects in one go with meson-build without utilizing git-submodules or any Cmake-Meson-build-glue-scripts. I realized that the meson-build integration is not consistent.
This makes things quite difficult, as it would require to install librz and rz-ghidra in order to debug or check them.
However, meson offers good features to prevent such as situation (such as wrap-mode force fallback, etc.).
I therefore created a code-state where it is absolutely possible to develop all three projects within one build folder with just one silly work-around to make the sleigh-language-defs available to cutter (install it temporarily in the build-dir, c.f. below).

Describe the solution you'd like

The idea is really easy written, but rather complicated and cumbersome to achieve. It was necessary to do the following things:

• Make it possible to add rizin as a subproject to cutter, by (closes: Make a Meson Wrap for Rizin library rizin#3454)
  • Making it possible to configure rizin, even if rizin_exe target is not required, nor build
  • Adding or updating all necessary wrap-files to rizin for potential
  • Several smaller fixes for includes and deps in rizin
  • Replace add_global_arguments against add_project_arguments (addressed previously in: meson: do not use add_global_arguments() rizin#3706)
  • Making it possible to use the meson_git_wrapper.py from a subproject
  • Replace the project-version with a meson-compatible version (i.e. without the v-prefix)
  • Get rid of the check_meson_subproject_py-commands! These are redundant with mesons
    force_fallback- and wrap_mode-options and introduce incompatbilities.
  • Get rid of the static_runtime-option! This is redundant with mesons built in
    prefer_static-option
• Make it possible to add rz-ghidra as a subproject to cutter, by
  • Creating a subproject, including a wrap-file and packagefiles for ghidra
  • Adding meson-build scripts for rz-ghidra
  • Adding other wrap-files to rz-ghidra (such as rizin)
• Add everything to cutter
  • Add wrap-files for rizin and rz-ghidra
  • Add meson-build scripts

The linked branches could then be tested, by configuring a build-directory (in the cutter-branch) with:
meson setup -Dwrap_mode=forcefallback -Dprefix=$(pwd)/build/install build
and compile it with:
ninja -C build install

Describe alternatives you've considered

I'm not sure if this is in anyway desired or appreciated...

My meson-proposal lacks several features that are currently available in CMake (such as RZ_LIBSWIFT, RZ_LIBYARA, etc.)

I know this still has a far way to go. However, I think there are great opportunities! E.g. using sanitizer, toolchains, configurations, compiler-features or dependencies consistently over all parts of the project during development or even packaging. I really appreciated meson-build in the past and I hope there is appreciation for it here in the cutter/rizin community as well.

Additional context

Please note the list of branches that have been created to support this effort:
(NOTE: Branches are listed in the necessary order to merge them!)

1. https://github.com/amibranch/rizin/tree/rizin_as_subproject
2. https://github.com/amibranch/rz-ghidra/tree/add_meson_build
3. https://github.com/amibranch/cutter/tree/add_meson_build

Pull-Requests from these branches will be created, only if feedback to this issue is available.
Please note: The branches do not yet apply most of the developer-guidelines to the underlying projects (specifically regarding testing and documentation)

[karliss]

For reference previous cutter meson build support removed ~4years ago due to being incomplete, insufficiently maintained and partially depending on qmake project #2546 . I don't remember what was the exact state of meson build system on rizin side. If I am not mistaken there where quite a few meson build system changes that happened after the r2/rizin fork.

I personally don't feel very excited about the idea of Cutter build system rewrite.

If you want to further evaluate the amount of potential changes and work required on Cutter side my recommendation is instead of optional projects like RZ_LIBSWIFT or RZ_LIBYARA start with stuff like:

• cutter packaging/build 3 major scenarios
  • cutter release packages
  • development builds
  • Linux distro system builds
• support for build on older systems
• python bindings
• various dependency handling cases
  • system libs not in the usual places (cutter deps)
  • dealing with multiple system python versions
• external plugin compilation against prebuilt Cutter (which could be one of the different setups described previously)
• multiple qt versions

As for merging order if it ever gets that far, the more likely scenario (ignoring any additional libs) might be:

• improvements on rizin side
• the meson build on Cutter side
• transition on Cutter side
• cleanup of now unnecessary functionality on rizin side
  Stuff used by current setup can't be removed unless it's clear that ALL currently supported usecases are covered.

Are there any improvements on rizin side which would improve the compatibility with such setup, but do not affect the current setup or introduce duplicate work?

[amibranch]

Thanks for highlighting the previous meson-build integration. I wasn't aware of that transition.

Generally, I don't see any deal-breaker in your points and I would be willing to try it (and therefore rewrite large parts of the build system). However, I'm of course highly biased.

Therefore, first things first - here are my views on these points:
(TL:DR? -> skip to "In the end..")

• I think the qmake-dependency is much easier to implement nowadays, compared to the linked changes. Since meson natively added support for different Qt-dependencies with the integrated modules ( Qt4, Qt5 and Qt6). These are the Qt-versions that could be easily supported in meson-build. I guess everything earlier wouldn't be impossible, but just more effort.
• However, these modules depend on qmake. I'm not sure, if you are really mean there is a need to have no dependency (not even a build-dependency) towards qmake? Isn't it required to compile moc- and uic-files for Qt? (Excuse if the question is silly - I'm not too much into Qt)
• AFAIS, rizin seems to use meson.build as their primary build-system. At least I haven't found a different one yet and their travis-script is building with meson (https://github.com/rizinorg/rizin/blob/08acf54585d35ba8a0470b78a070a06817ae3200/travis-script#L39) and there is even a blog-post about it (https://rizin.re/posts/why-meson/). However, there are some problems (as seen by the linked issues and PRs). It was the point that surprised me, as the "main-project" used meson, while the plugins (at least rz-ghidra) did not.
• I think it's already in the current state possible to create release packages for cutter and rz-ghidra with meson-build on my branches
• By "development-builds", do you mean packaging of debian-style -dev-packages or just a build-configuration that could be used for development (-O0, -g, etc...)? The latter is absolutely no problem with meson-build (even though there are several options on how to do it - I kept it simply and used mainly the -Dbuildtype=[release|debug]-option, similar to most CMake-integrations)
• "Linux distro system builds" - I don't see any problem with that and meson-build. However, some distros (mostly debian-based) use dated meson-versions. In the special case, where it is necessary to package a current version of a meson-build-based software, on such a system, I would recommend to install a recent meson-version e.g. via pip (just for building the package). However, I don't hope this is a real use-case. Most of the packages in a distro are typically coordinated (meaning, a backport of patches on e.g. cutter to the old version of cutter in that distro should still build with the tools versions in that distro). Please explain, if I miss here something, as I have very little experience in packaging distros, beside rolling released ones.
• Meson offers version-checks for different features (comparable to cmakes Compatibility Matrix). Supporting building on older systems is imho much easier with meson, as it is only based on python and therefore mostly portable even to dated platforms
• It is no problem to adapt to different python-versions within meson-build. This is usually done, by the python-modules language-version-function. It was used in the past by some projects to switch between python python 2/3 or minor-version dependent features.
• I don't see how meson would make the dependency handling worse. I personally think that the native options in meson do allow a lot more fine-granular control about where which dependency will be taken from. In doubt it could be achieved or forced in meson as much, as in cmake, by specifying paths explicitly via configuration-options (as did rizin - even though I think that rizin is not a great example as it added some unnecessary options)
• The external plugin compilation problem was the reason why I started this work. I don't think that meson is here anyhow worse or better then cmake. It is rather a question (from my experience) on how to provide a template that specify features a plugin must or should provide to be compatible.
• Regarding your order of tasks: My branches only address the first two points. And I wouldn't bother about the third point, until everything is achieved and compatible.
• I'm not sure, if I understand your final question correctly. Cutter depends on rizin (not the way around). Therefore, adding meson-build to cutter will not affect rizin (but the way around, it does). If you ask me for arguments and benefits of using meson-build, I first and foremost say, it makes it easier to create the build-system for anything depending on it (mostly plugins). However, there are more benefits (e.g. it is in my branches as easy, as adding -Db_sanitize=address while configuring cutter to add ASAN to all dependencies - not only rizin and cutter, besides of QT).

In the end..

If I were in your position and only got objections or claims to my concerns on an initiative like this, I would stop it straight away. I therefore propose to test and verify if meson is capable to fulfill the requirements with dedicated examples and tests.
However, to do so, I would kindly ask if there is an official compatibility list of systems, distros or even dependency versions? If not, could you provide the distros, timeframes (i.e. "last X years"), architectures, Qt- and python-versions that needs to be supported (only for cutter! As the situation for rizin shouldn't change)? I've only found that the current CI-pipeline is testing against x86-64 ubuntu-latest - the cutter-website only links to rizin releases. But maybe I'm missing it.
In doubt, I would already be happy if you could link me to some issues from the past where such use-cases had been specified - so that I could start testing against them.

Why is it worth?

I know that there are a whole bunch of arguments why meson-build should not be preferred. However, I personally could argue and provide examples against most of them. Mostly, because meson-build gave me fewer and shorter headaches (if at all), compared to other build-systems.
However, this is just from my experience and I'm as biased as most authors of the linked posts are.
If you, as maintainer, say "We don't want meson here and are happy with Cmake", I totally understand this and it is sometimes absolutely necessary to step back and objectively do not fall further into a "sunk-cost" problem.
This would be a good point in time to stop it.
If so, I would just polish and finish the improvements for rizin and stop the efforts for cutter and rz-ghidra here.

[karliss]

No nothing was meant to be a total dealbreaker, and I have no doubt's it's possible to make it work if enough work gets put it in. This was meant more of as a warning that you have long way ahead and list of things to watch out and pay attention to if you decide to continue with it.

Isn't it required to compile moc- and uic-files for Qt?

Qmake and the moc/ui stuff are two completely different things. The first one was a build system just like CMake or meson is. The later are just simple tools executed during the build process. Qt themselves have moved away from it in favor of CMake. And by dependency on qmake I was referring to fact that the old Cutter meson project was reading values out of Cutter qmake project file (as a hack do avoid some duplicate definitions between the qmake and meson projects). If the meson or CMake qt module under the hood invoke qmake for resolving some stuff, that by itself isn't a problem, and does so correctly without getting confused by multiple qt installs then that's not an issue.

AFAIS, rizin seems to use meson.build as their primary build-system
Yes meson is currently the primary build system for rizin, but before that there was sys/install.sh which If I am not mistaken was a wrapper around automake based project. And the switch to meson as primary build system was proably reason why that blog post was created. But as I said before I don't remember all the details from 4-5 years ago.

I think it's already in the current state possible to create release packages for cutter and rz-ghidra with meson-build on my branches

Based on how little there is in meson.build of your cutter branch I highly doubt that.

By "development-builds"

By development builds I was referring to the builds that developers would do locally while working on Cutter.

"Linux distro system builds" - I don't see any problem with that

Primary concerns with distro builds is:

• making sure all the files which need to be installed are installed in the right places
• cutter can be built without the build system downloading stuff during build process or forcing certain bundled libs when it shouldn't (in theory meson should be good at this, but still that's assuming everything is set up correctly)
• making sure cutter can be compiled against rizin that's built and installed as separate system package
• allowing rz-ghidra to be compiled to be compiled and installed seperately against the system rizin/cutter pacakges
• not doing the stuff which is only relevant in the self contained Cutter release builds
• Setting that up (by distro packagers) with relatively minimal amount of configuration and avoiding need for obscure flags. For reference here are the configs Arch uses https://gitlab.archlinux.org/archlinux/packaging/packages/rz-cutter/-/blob/main/PKGBUILD?ref_type=heads https://gitlab.archlinux.org/archlinux/packaging/packages/rz-cutter/-/blob/main/PKGBUILD?ref_type=heads .

Old meson versions is a separate topic . If there is a hard dependency on some feature which is only available in latest meson that's problematic. There needs to be some window of less than latest meson support. Even rolling distros don't update their packages instantly. But preferably decently fresh but not rolling distros like latest version or two Fedora should also be able use the meson they have.
As for stuff like 5 year old debian that stuff isn't going to distribute latest Cutter version anyway.

It is no problem to adapt to different python-versions within meson-build.

Python2 support isn't needed at this point. Biggest thing to watch out here is distros like Ubuntu which can have multiple different python 3.x installed at the same time.

Regarding your order of tasks: My branches only address the first two points. And I wouldn't bother about the third point, until everything is achieved and compatible.
I'm not sure, if I understand your final question correctly.
From your initial description it wasn't quite clear if al all the changes you are planning on rizin side are also compatible with the existing Cutter setup. My main concern was avoiding a situation where changes are made in rizin with hopes that cutter will be updated accordingly, forcing either to urgently make major changes in Cutter or reverting the changes in rizin.

One more tiny concern (but not very important) is about the state of meson support by various IDEs. As a result of this discussion I checked the latest meson docs and was pleasantly surprised that things are better than they whey few years ago. At the same time I still have (personal) feeling that overall support by c++ ecosystem is better for CMake than meson. In QtCreator and VisualStudio CMake has first class support, and for CLion if I remember correctly that was the first build system they supported. In theory meson currently has some support for main IDEs, but at the same time QtCreator lists the support as " Many features available with Meson build or usually available from Qt Creator are missing", Visual Studio requires on meson generating a VS project instead of direct support (which is what CMake had long time ago). XCode situation is probably equal for both. VScode and CLion plugins are probably fine although I haven't had chance to properly evaluate them.

ve only found that the current CI-pipeline is testing against x86-64 ubuntu-latest - the cutter-website only links to rizin releases.

Go back to GHA ci scripts and keep reading everything relevant is there. If you only noticed x86-64 ubuntu latest you didn't read it carefully enough. Also where do you think release come from?
For the most extreme case Ubutuntu 18.04 against system libs which also means last version of Qt5 but not older (with potentially meson and CMake being only things which are installed separately). But there is also a bunch of newer versions that are tested. Not included in CI test, but on something like fresh Arch should be able to fully build against system libs (as much as rizin permits it). Not quite sure if CMake was supposed to be installed in the later currently tested Ubuntu builds, that might be a mistake.
But for the exact details check CI scripts again you will be expected to work on them anyway together with build system changes.

Final words
At no point I am question of what the benefits for having meson build would be. It's more of concern whether it's worth the extra work and time.

As a mainter (but I don't claim to represent the opinion of all maintainers or have the authority to do so, especially my the amount of my recent activity) I am happy enough with current state (even though there are parts that could be better) But I am also not completely against the possibility of having full meson build and if you showed up with a set of branches that have full feature parity with current setup, I would review it and even consider it for fully replacing existing one (only if the parity is actually there). Also I have no interest in maintaining half finished version of meson build or maintaining two build systems for Cutter in parallel.

So decide for yourself if you are willing to put in a lot more time into this, considering a possibility that it will be rejected and thrown away if you don't reach the parity. Expect there to be lot of back and forth during the review process, and be prepared on working and testing on many different systems.

[amibranch]

Regarding your points:

• Qmake: I will digg further into it
• Release packages: I wouldn't say the output of the branches is comprehensive or achieved parity (just by comparing the install-dirs output with my locally available package, I found the translations are missing, etc.) - so I think, I got your point
• Everything mentioned regarding linux distro builds is possible and was intended by my build scripts without any hacks or work-arounds. It's just a matter of configuration (and I could and will provide the examples at some time - and if only via CI-scripts)
• Regarding recent meson versions: haven't checked yet on the branches, but should be possible to support dated meson-versions
• Regarding different python-installation: have seen some similar requirement in a meson-script in the past. Not the nicest thing, but no dealbreaker
• Regarding IDEs: I can't say much about IDE-support. If there is a concern about a specific IDE, it must be addressed of course. In doubt, there is always the possibility to wrap meson-build by a Cmake-script and translate configuration options (similar on how qemu did it with automake and meson - however, IMO they provided the very best example how not to do it)
• Regarding CI-scripts and current support: I will investigate them and ask, if questions occur

My current plan on how to proceed from here:

1. First I will start preparing the pull-request on rizin. Most changes there are necessary, independent of the further work on cutter and rz-ghidra.
2. I will then improve and test the meson-branch on cutter in a rudiemntary way (i.e. achieving full parity with the arch-linux package and the recent packages in a newer ubuntu-distro - 24.04 I guess). If this achieves a "stable" state, I would setup a pull-request here and give it a first round of reviews (explicitly without the goal to merge it. Merely to receive broader feedback and identify any "bigger" unresolved questions)
3. Afterwards I will start testing against all the required distros and systems (including windows, mac, ubuntu 18.04, latest two fedora versions, aarch64, ppc(?), etc.) - I guess at that point I would also touch the CI
4. Anything else (especially if this should proceed) should only be discussed earliest somewhere around point 2 (including creating PRs for rz-ghidra or other plugins, creating Cmake-wrapper, ...). As a working meson-build integration in cutter would be a precondition for it