[RFC] Switch to CMake build system

[ahippo]

This is not intended to be merged right now,
(as it's known to lack some of the features of the existing build system)
but is more like a request for comments.
Also, CMake might be used side-by-side with the existing Makefile-based build system to ease adoption.

Currently incomplete features:

• version generation based on git information;
  (currently done at configure time,
  not build time, so can get stale easily)
• libattr autodetection;
  (might need to be reworked for <sys/attr.h> change)
• RPM/DEB packaging might be lacking something;
• TGZ (source code) packaging is incomplete.

[trapexit]

I'm not super familiar with cmake. Looks generally ok but could you explain the reasons for / benefits in this change?

[ahippo]

could you explain the reasons for / benefits in this change?

To some extent, it was an exercise to see if CMake-based build system will be more concise than Makefile-based one.

Also, CMake supports certain building/installing/packaging/cross-compilation conventions out of the box, so might be easier for distros to support.
For example, in Gentoo there are generic functions for configuring, building, installing CMake-based packages, and thus build recipes are simpler to write and maintain (they might be almost empty), then for hand-written Makefiles.
autotools are also standard for this matter (when used conventionally), but CMake is kind of more modern.

CMake is also able to produce RPM and DEB packages directly, which could simplify packaging a bit.
(and deduplicate/remove .spec and control files)

[slashbeast]

+1 for that.

CMake makes it's possible to integrate mergerfs without much of effort, supports crosscompilation among others out of the box and so on.

@ahippo any bump for this pull request?

[trapexit]

I'm still not sold on the change. I've less experience with cmake but the reason I've not used any build systems is because a number that I have used break from time to time and not always easy to fix. Perhaps cmake is better but I've been bitten a number of times.

[slashbeast]

I honestly cannot think where cmake or meson, what is another good build system, could break.

• You specify source files, even via glob, and you compile them
• You use add_executable() to link the executable
• You have full integration with pkg-config to find packages like libfuse for example.

And the best part is that you can then integrate it within distro without much of effort, cross compile it if you wish, I see only benefits.

Even if build breaks, you can then open link.txt files that are generated and copy-and-paste the command that failed.

Really, CMake is the way to go.

[trapexit]

re: meson

I've had many problems with meson due to it or ninja requiring specific versions of Python. It was one of the reasons I vendored libfuse. I couldn't build libfuse3.x on old platforms. It requires Python 3.5. That's too new for some platforms I build for. GNU Make, POSIX shell, C, work most anywhere.

[slashbeast]

Meson is in python so sure it has runtime dep on it, CMake can be built statically. I used to have latest CMake few years ago on rhel5 build servers, Static CMake was the solution, later I switched to crosscompiling. All you really need is a sysroot for headers and libraries, CMake have CMAKE_TOOLCHAIN_FILE support where you can specify the sysroot you build for, and then a regular CMake-based build system can be crosscompiled.

[trapexit]

A static cmake is fine and all but my concern is the available version on a random distro. I'm not going to be vendoring static binaries of cmake or requiring to download special things to build.

[slashbeast]

Depends on what's the oldest distro you want to support .You can also have more than one build system. For instance, qbittorrent have autotools and CMake, and user chooses what to use, with mergerfs it should be feasible to have CMakeLists.txt along your Makefile, everyone would be happy

[trapexit]

Depends on what's the oldest distro you want to support

As far back as my users have. https://github.com/trapexit/mergerfs/releases/tag/2.28.3

You can also have more than one build system

I don't understand the point of that if what I have now already works on everything I've tried or can be made to with minor tweaks. Supporting more build systems is worse than a new system because then I need to test it across every system. I shouldn't but I do because in my experience build systems are not reliably backwards and forwards compatible. autotools and meson especially. If cmake works, without hacks, across all OSs I currently build for and gives me more than I have now I'm open to using it but the reason I didn't use it in the first place was because of the general risk large build systems impose that I simply didn't want to mess with or worry about.

[slashbeast]

I'd recommend you to try the CMake, give it a chance, they changed interfaces between versions, but if you use manual of the oldest version that is in the oldest distro you support, it will work on new CMake too, it's forward compatible.

From my point of view, I now add mergerfs into Gentoo and instead of just hooking it like any common software I need to modify Makefile a bit, strip -O2 from there and so on. From maintainer point of view, autotools or CMake are huge help, tho I prefer CMake, autotools not nice.

[trapexit]

If there are standard values like DESTDIR and whatnot for optimization flags... I'm happy to add them.

[ahippo]

@slashbeast, since you're adding mergerfs to Gentoo, you may want to take a look at my previous PR attempt: gentoo/gentoo#9544

any bump for this pull request?

Unfortunately, I don't have time to work on this much.
It mostly worked for me when I created the PR, so, please, feel free to pick it up.

A static cmake is fine and all but my concern is the available version on a random distro
CMake has been around for a while,
Both CentOS 6 and Ubuntu Trusy (14.04) have cmake-2.8, which is "almost modern".

[slashbeast]

If there are standard values like DESTDIR and whatnot for optimization flags... I'm happy to add them.

Currently you add them on the top of CFLAGS, meaning if I run make CXXFLAGS='-O3' you will override it with $OPTS. It should be defined as CXXFLAGS in Makefile, that end user can override later

You could change it in a way, where you call ${CXX} ${CFLAGS} to call ${CXX} ${FUSE_FLAGS} ${CXXFLAGS} so you append your default flags to CXX, and user can still override them withoung modifing Makefile.

[trapexit]

@slashbeast Does https://github.com/trapexit/mergerfs/tree/mount work?

[slashbeast]

@trapexit this link gaves me 404.

[trapexit]

I merged it. It's in the main branch now.

[slashbeast]

I see the commit on master, very nice, thanks!

[trapexit]

Let me know if I missed anything.

[eli-schwartz]

I've had many problems with meson due to it or ninja requiring specific versions of Python. It was one of the reasons I vendored libfuse. I couldn't build libfuse3.x on old platforms. It requires Python 3.5. That's too new for some platforms I build for. GNU Make, POSIX shell, C, work most anywhere.

FWIW, there is https://sr.ht/~lattis/muon now, which is a c99 reimplementation of meson which has broad support for the meson DSL. It should build and function on any POSIX environment with a c99 compiler (not a high bar) and depends on https://github.com/michaelforney/samurai instead of Make -- which also is written in c99. (CMake optionally generates either Make or ninja/samurai files, but cmake is a lot more complicated to acquire/build than muon is.)

If cmake works, without hacks, across all OSs I currently build for and gives me more than I have now I'm open to using it but the reason I didn't use it in the first place was because of the general risk large build systems impose that I simply didn't want to mess with or worry about.

One advantage of meson or muon, which you do NOT get from cmake, is the ability to seamlessly use libfuse as either:

• a system library
• a meson subproject: https://mesonbuild.com/Wrap-dependency-system-manual.html

Since libfuse already uses meson, it becomes incredibly easy when using meson, to depend on libfuse.

libfuse builds fine with muon, so you could stop vendoring it (meson uses an ini file describing where to download it from, and when resolving via wraps, will download it if needed).

[trapexit]

"the ability to seamlessly use libfuse"

This is irrelevant as mergerfs uses a builtin version of libfuse.