Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add cmake support #76

Closed
wants to merge 29 commits into from
Closed

Add cmake support #76

wants to merge 29 commits into from

Conversation

tobq
Copy link

@tobq tobq commented Dec 9, 2022

No description provided.

jcelerier and others added 29 commits September 5, 2019 23:47
Fix CMakeLists.txt for MSVC (tested with Community 2017)
committer: GitHub <[email protected]>
Co-authored-by: Jan Holthuis <[email protected]>
@cannam
Copy link
Member

cannam commented Dec 12, 2022

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 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.

@cannam cannam closed this Dec 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants