Support Meson

[debarshiray]

I am overhauling GEGL's current LibRaw based RAW decoder and switching it over to Rawspeed. Unfortunately, having CMake as the only build system is causing some pain. Having Rawspeed support the Meson build system would make my life a tad simpler.

I am currently prototyping the new decoder inside the GNOME Photos application, which has switched from Autotools to Meson; and a Meson port for GEGL is currently underway.

[LebedevRI]

I am overhauling GEGL's current LibRaw based RAW decoder and switching it over to Rawspeed.

Interesting.

Unfortunately, having CMake as the only build system is causing some pain.

I'm guessing here the problem isn't cmake itself, but the fact that gnome world has decided to be innovative, and gone with a whole new build system, which isn't cmake?

Having Rawspeed support the Meson build system would make my life a tad simpler.

I can certainly see why this may be a problem. But i'm not sure how this can be addressed.

I'm not aware of any success stories of maintaining more than one build system, without them getting out of sync.

And, i don't like cmake, but i don't see any viable alternatives to fully migrate away to.

[debarshiray]

Unfortunately, having CMake as the only build system is causing some pain.

I'm guessing here the problem isn't cmake itself, but the fact that gnome world has decided to be innovative, and gone with a whole new build system, which isn't cmake?

Well, if it wasn't Meson, then it would've been Autotools. :)

The move to Meson isn't just limited to GNOME, though. Off the top of my head, I can think of GStreamer, Mesa, the X server and Weston.

Having Rawspeed support the Meson build system would make my life a tad simpler.

I can certainly see why this may be a problem. But i'm not sure how this can be addressed.

I'm not aware of any success stories of maintaining more than one build system, without them getting out of sync.

Normally, I'd agree that having multiple build systems on a long-term basis is a problem. However, I think modules that are meant to be used as Git submodules are an exception. eg., the libgd module, which is a collection of prototype GTK widgets shared across multiple applications supports both Autotools and Meson.

The idea is that if there are people interested in integrating with a specific build system, then those people get to maintain that specific build system. In that sense, I don't mind helping you keep the meson.build files updated.

[LebedevRI]

There is any number of build systems out there (autotools, cmake, meson, gn, build2, bazel, ...) Will it be okay to accept to maintain exactly two of them, but not more? Why? Any answer here is hypocrisy i think. I personally think a single choice is least hypocritical.

Now, if the answer is not one, but e.g. two. Should the builds with the two be exactly feature-for-feature compatible? Should they produce bit-by-bit identical binaries? That adds some unspecified testing steps for ^ these requirements. And the first one is certainly not possible because e.g. the 'external projects' it can build (googletest, googlebenchmark, pugixml, llvm-openmp, zlib; libjpeg soon) are mainly cmake-based. Should that buildsystem act much like the gpl cancer, and try to spread to those libraries?

You don't have to use the library. You don't have to track it via a git submodule. The simplest alternative is to copy it in-tree, rip away the cmake stuff, and add your own meson build system. That way it will certainly work for you. I'm not sure, maybe you can also do a mixture of two, track as submodule, and place the meson buildfiles out of the submodule somewhere.

gnome&friends were using autotools; at the time they have decided to switch to meson, cmake was well-established and very widely used, pretty much all the crappy stuff it was known for is just due to legacy cmake usages from 2.x era, and outdated blogposts. This sounds like it's self-inflicted problem, so i'm afraid i will have to suggest to handle it on your end :(

[parafin]

Probably build system (meson) can just call external build command (cmake) and import the result as a pre-compiled library afterwards.

[LebedevRI]

And the first one is certainly not possible because e.g. the 'external projects' it can build (googletest, googlebenchmark, pugixml, llvm-openmp, zlib; libjpeg soon) are mainly cmake-based. Should that buildsystem act much like the gpl cancer, and try to spread to those libraries?

Oh, forgot the main question here: Let's suppose a dependency is being added, on another copylib. (abseil e.g., #122) Last time i checked it only supports building with bazel and cmake. Should that be a show-stopper? Or will it be okay to suddenly stop supporting meson? Or will one have to add meson support to that copylib?

[debarshiray]

There is any number of build systems out there (autotools, cmake, meson, gn, build2, bazel, ...) Will it be okay to accept to maintain exactly two of them, but not more? Why? Any answer here is hypocrisy i think. I personally think a single choice is least hypocritical.

It depends on who wants to use it. For the sake of argument, if some bazel-based project wants to use Rawspeed, then I'd expect them to contribute the bazel support to Rawspeed and maintain it.

I certainly don't expect the existing pool of Rawspeed developers to support all the world's build systems on their own.

[LebedevRI]

I am overhauling GEGL's current LibRaw based RAW decoder and switching it over to Rawspeed.

Is there a writeup somewhere about this? Why is that being done? Perhaps it would be simpler to not switch away from a real library?

I'd expect them to contribute the bazel support to Rawspeed and maintain it.

I certainly don't expect the existing pool of Rawspeed developers to support all the world's build systems on their own.

[Why] Does this have to happen upstream? What specific problems are there to do either

• wrap around cmake or
• maintain the buildsystem downstream

?

If upstream is only meant as a storage, then any other build system other than the main one will not be tested upstream, considered arbitrarily broken and bitrot, and not recommended for use. And with that in mind, i'd very much prefer to avoid adding such volatile things into tree in the first place..