This has been reviewed already (see #18) at which time it was a proposal for a more portable, vcpkg-friendly replacement for Rubber Band's old autotools build system.
At that time I decided to go with Meson instead of CMake, partly because of personal preference - I use Meson elsewhere and find its syntax and semantics reasonably transparent (whereas I think CMake is kind of incomprehensible) - and partly because other commenters accepted that it would solve their original problem, which was to integrate with vcpkg on Windows and elsewhere. In that PR I was persuaded against the idea of trying to support more than one fully-fledged build system at the same time.
My general principle since then has been to have one "main" build system - this is the Meson one, which is capable of building any supported target with any supported combination of options on the primary desktop platforms - plus potentially any number of specialised build scripts in the otherbuilds directory. The latter are pretty basic and build only the library, in a single configuration each, so that they don't have multiple combinations of options to test.
The "main" build system for Rubber Band of course is quite complicated and supports a fair number of different options and targets, which is why it makes sense to have only one of it. Apart from a recent peculiarity with JNI autodetection, Meson works pretty well, I don't really wish to switch away from it at this moment, and I am also conscious of the arguments against adding a second top-level build system. My suggestion would be to use Meson to build Rubber Band rather than trying to add something else to do it - but if that is not working for some reason, I'm open to hearing about it.
Hi - thanks for the PR!
This has been reviewed already (see #18) at which time it was a proposal for a more portable, vcpkg-friendly replacement for Rubber Band's old autotools build system.
At that time I decided to go with Meson instead of CMake, partly because of personal preference - I use Meson elsewhere and find its syntax and semantics reasonably transparent (whereas I think CMake is kind of incomprehensible) - and partly because other commenters accepted that it would solve their original problem, which was to integrate with vcpkg on Windows and elsewhere. In that PR I was persuaded against the idea of trying to support more than one fully-fledged build system at the same time.
My general principle since then has been to have one "main" build system - this is the Meson one, which is capable of building any supported target with any supported combination of options on the primary desktop platforms - plus potentially any number of specialised build scripts in the
otherbuildsdirectory. The latter are pretty basic and build only the library, in a single configuration each, so that they don't have multiple combinations of options to test.The "main" build system for Rubber Band of course is quite complicated and supports a fair number of different options and targets, which is why it makes sense to have only one of it. Apart from a recent peculiarity with JNI autodetection, Meson works pretty well, I don't really wish to switch away from it at this moment, and I am also conscious of the arguments against adding a second top-level build system. My suggestion would be to use Meson to build Rubber Band rather than trying to add something else to do it - but if that is not working for some reason, I'm open to hearing about it.