-
Notifications
You must be signed in to change notification settings - Fork 96
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
Implement CMake build script #18
Conversation
Fix CMakeLists.txt for MSVC (tested with Community 2017)
…lable in newer macOS
Hello there - thanks for proposing this! I'm not a CMake user; can you give me a quick summary of how to test this? |
Hi !
should do it. Add It's possible to create .vcxproj (default on windows) with I have only ported the features that I needed but I can add what's missing if you intend to merge :) |
Hi again - sorry about the delay. The default build and the basic options you mention appear to be working, thanks! I have pulled your changes to a branch called "cmake", and in principle am happy to merge. Because Rubber Band Library is not maintained in a Git repo (this one is just a mirror), I've done so by pulling the commits from your branch here to the upstream Mercurial repo, rather than use the Github pull request logic. (The upstream repo is at https://hg.sr.ht/~breakfastquay/rubberband and the changes have been mirrored back here. I've no problem with pulling any further commits from your repo also, no need for you to engage with that repo) I do have a few questions:
Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this also work for building the DLL on Windows?
There will be bugs specific to one build system or another if you try to maintain multiple build systems. I highly recommend to remove the other build systems after merging this. There is no point maintaining build systems that CMake can generate. @cannam would you be okay with that? |
@Holzhaus I don't think it would be very hard to build the Windows DLL. I think you'd need to unconditionally build the main library statically when using MSVC and build the files in the rubberband-dll folder if BUILD_SHARED_LIBS=ON. The Visual Studio project file also defines a few preprocessor definitions. CI should build both statically and dynamically, at least with MSVC. |
Co-authored-by: Jan Holthuis <[email protected]>
sorry @cannam I had completely forgot to answer..
oops, okay, so the CMake version should be the project version, and then we should set the library version (SOVERSION property) so that on linux we get librubberband.so.2.1.1
ok will do
sure, no worries. May I encourage you into looking at CLA Assistant which is made to automate this process ? (https://cla-assistant.io/) Regarding the CMake JNI PR, the best way would be to merge both - from what I can see it's mainly about adding another rubberband-jni target on android (or even if one wants to have desktop Java bindings) which will add the JNI specific source files. I don't particularly have time today to look at all that but doing my best to finish that PR quickly :-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm working on some fixes.
CMakeLists.txt
Outdated
target_compile_options(rubberband | ||
PRIVATE | ||
$<$<BOOL:${APPLE}>:-mmacosx-version-min=10.11> | ||
$<$<AND:$<NOT:$<CXX_COMPILER_ID:MSVC>>,$<CONFIG:Release>>:-ffast-math ${MARCH_NATIVE_FLAG} -O3 -ftree-vectorize> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally find these generator expressiong very hard to read. This would be much more straightforward IMHO:
target_compile_options(rubberband | |
PRIVATE | |
$<$<BOOL:${APPLE}>:-mmacosx-version-min=10.11> | |
$<$<AND:$<NOT:$<CXX_COMPILER_ID:MSVC>>,$<CONFIG:Release>>:-ffast-math ${MARCH_NATIVE_FLAG} -O3 -ftree-vectorize> | |
if(APPLE) | |
target_compile_options(rubberband PRIVATE -mmacosx-version-min=10.11) | |
endif() | |
if(NOT MSVC) | |
target_compile_options(rubberband PRIVATE $<CONFIG:Release:-ffast-math ${MARCH_NATIVE_FLAG} -O3 -ftree-vectorize>) | |
endif() |
I'll open a PR.
CMakeLists.txt
Outdated
PRIVATE | ||
$<$<BOOL:${UNIX}>:USE_PTHREADS> | ||
$<$<BOOL:${APPLE}>:HAVE_VDSP> | ||
$<$<BOOL:$<CXX_COMPILER_ID:MSVC>>:__MSVC__ WIN32 _LIB NOMINMAX _USE_MATH_DEFINES USE_KISSFFT> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does this specify USE_KISSFFT on MSVC in any case? We may be using FFTW3...
Also, if I understand that weird Microsoft XML thingy correctly, WIN32
is only specified for 32 bit builds, not all windows builds.
ANd the same applies here, I think an if/else ladder would be much more readable than all these genexprs.
I granted you access to my repo if you want to push directly on it.
iirc I followed how the current build system worked on that, see e.g. rubberband/rubberband-library.vcxproj Line 78 in d058064
|
@cannam I think this is ready to merge. |
I've pulled these changes to the I was happy (and in principle still am) to include a CMake build script simply because there is apparently demand for it. But as I've mentioned, I've no immediate use for it myself, it isn't the build system I would pick if I were starting now, and increasingly the arguments proposed in its favour are suggesting that it isn't a great idea unless it's the primary build system and it might also be more difficult to switch away in the future. Even as I can see the logic for some consolidation, I'm not all that happy with that proposition. I've set up an alternative branch with a Meson build (the branch is called |
Personally I don't care if you pick cmake or meson, as long as it's a cross platform build system that is reasonably easy to integrate into vcpkg. Building software on windows is extremely painful, and vcpkg at least makes it a bit easier. Does meson support symbol exporting like cmake does? Otherwise you'll need to put these ugly |
I can agree with that
I don't think it does have a built-in mechanism for this. At the moment my Meson script builds only a static library on Windows. I take it that, for integration with vcpkg or whatever, shared libraries are essential? (My own limited experience has been that static libraries are so far preferable on Windows that there wasn't much reason to care about this) I'll have a look at what the options are - I certainly don't intend to be adding export declarations so this may be significant. |
You're right: mesonbuild/meson#2132
For vcpkg it's possible set a lib to "static only". Unfortunately, it's kind of inconvenient to mix static and dynamic libs and we'd like to use dynamic libs for our dependencies. The alternative is to use Def files. Someone suggested to take the Def file generated by cmake, strip out the unneeded symbols and use that for meson dll builds. That won't for you to clutter your source code with this Microsoft-specific stuff. |
that wouldn't be too bad though... if I'm not mistaken just adding one for
would be enough, no ? and would likely reduce the size of the .dll. (I personnally only use the static library so I don't really care though. Even if it has a very important implication if using fftw on windows - it means that the host app does not need to call |
Huh: https://docs.microsoft.com/en-us/cpp/cpp/using-dllimport-and-dllexport-in-cpp-classes You learn something new every day. Thanks! I'd have to export the |
IIRC an issue with static libraries on Windows with Mixxx was that linking required an absurd amount of RAM, though I'm not sure if that was because of a compiler flag we used or if that's just how it works with MSVC. |
It's not a great idea to support multiple build systems regardless of what they are. It would also be a bad idea to support Meson and autotools, so I don't understand what advantage Meson would bring. However, as long it is easy to build on Windows and Unix and supports static and dynamic linking on all platforms, Meson would be fine. But we've already done the work for you here with CMake and it is verified to be working on Linux, macOS, and Ubuntu with CI. |
I'm trying to test the CMake build on Windows, specifically with regard to shared libraries. I've tried it with both msbuild and nmake back-ends, but in both cases it only seems to produce a static library target. Does the CMake script in this PR have support for building a DLL and if so, how do I enable it? I was specifically interested in what it did about library naming in the case where both static and dynamic libraries are built - on Windows this is problematic because of the import library associated with a DLL, which is usually given a |
Pass |
Thanks. That builds only the shared libraries - is it possible to tell it to build both? (Edit: oh, or does it? I was assuming |
Your assumption is correct. You can build both by using 2 separate builds dirs, otherwise the lib files would conflict I guess. |
I don't understand why anyone would want to build the same library both statically and dynamically simultaneously. |
I think it's really a question of perspective. If it is just "another build system", added because some people asked for it, then I don't really mind what it's like, so long as it works ok. But if it's the primary or only one, then I will be using it as well, and so I am likely to have stronger views about what it consists of and to want it to have more in common with systems I'm using elsewhere. |
This is the big reason for using CMake over Meson. The C/C++ ecosystem is generally converging on CMake. Qt6 now uses CMake. Microsoft Visual Studio includes CMake now. Microsoft's vcpkg is built with CMake too and using CMake makes it trivially easy to package libraries in vcpkg (which is the motivation for @Holzhaus and me working on this). |
Of course you can build both static and shared libs simultaneously when renaming one of them: https://stackoverflow.com/a/29824424 However, this is pretty bad from the user's standpoint IMHO:
|
From a packagers perspective (packing on CentOS/Debian as my dayjob, and Nix by night) I can say: Don't use meson. It's the one build system we (dayjob) have the biggest problems with (except maybe autotools), because it pulls in python and with that a whole zoo of stuff. Just my 2ct, tho. |
One thing to consider: CMake's |
The next release will definitely use Meson. I'll keep an eye on feedback (including from commercial users) and may review later. I am actively working on Rubber Band at the moment, so (a) I am glad to have a build system I like working with, but also (b) there should be more releases to follow, giving options to review the situation. I'm also going to retain some of the previous build files in a subdirectory ( Thank you everyone for providing the impulse to review the build situation, and for all the work put into the proposed CMake scripts. If this decision turns out to be a bad one, then switching will be much easier with this work to start from. |
@cannam Any estimate when you will merge the meson branch into master? I guess when rubberband is available through vcpkg, it will not make much of a difference for consumers on Windows, wether you use Meson or CMake. And vcpkg improved their Meson support too. |
Actually it will make a difference because Meson has nothing comparable to WINDOWS_EXPORT_ALL_SYMBOLS for dynamic linking on Windows. Dynamic linking on Windows could be implemented on Windows with Meson, but this requires some more work than simply setting the WINDOWS_EXPORT_ALL_SYMBOLS property on a CMake target. |
You could add a https://stackoverflow.com/questions/9946322/how-to-generate-an-import-library-lib-file-from-a-dll |
Hello,
here's a build script to allow using RubberBand with CMake.
It's not finished yet, but if you want to review it it should not change much.