Devendor ableton link #4836
Devendor ableton link #4836
Conversation
| ${ABLETON_LINK_INCLUDE}/ableton/Link.hpp | ||
| ) | ||
| else() | ||
| include(../external_libraries/link/AbletonLinkConfig.cmake) |
There was a problem hiding this comment.
shouldn't this be included in a package distribution of Link? IIUC that is the correct way to distribute and use libraries with CMake support
There was a problem hiding this comment.
Hm, maybe you're right. This is what Debian ships.
I have not included the cmake files in packaging, because I didn't know where to put them.
Would /usr/share/ableton-link/ or /usr/share/link by the correct place for the .cmake files? Is there a standard for this?
There was a problem hiding this comment.
That being said: Debian also patches some of the files to make it compatible with a system asio (I do a similar thing, but ignore the .cmake files later on).
There was a problem hiding this comment.
Is there a standard for this?
AFAIK there is no single best practice, but a couple things that will work. according to the documentation for find_package, the following paths are tried with Linux:
<prefix>/(lib/<arch>|lib|share)/cmake/<name>*/ (U)
<prefix>/(lib/<arch>|lib|share)/<name>*/ (U)
<prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ (U)
where <name> is Link if find_package() is called with "Link".
if you call find_package without NO_SYSTEM_ENVIRONMENT_PATH then <prefix> will eventually be tried with /usr/. so a lot of potential options here. let me see if my copy of Professional CMake has a recommended best practice ;)
There was a problem hiding this comment.
btw, on my Arch system I see this:
[bheim@archlinux supercollider]$ find /usr -name *.cmake | grep -v /usr/lib/cmake | grep -v /usr/share/cmake | sort | less
/usr/lib32/cmake/DBus1/DBus1Config.cmake
/usr/lib32/cmake/DBus1/DBus1ConfigVersion.cmake
/usr/lib32/cmake/harfbuzz/harfbuzz-config.cmake
/usr/lib32/cmake/libxml2/libxml2-config.cmake
/usr/lib32/cmake/Ogg/OggConfig.cmake
/usr/lib32/cmake/Ogg/OggConfigVersion.cmake
/usr/lib32/cmake/Ogg/OggTargets.cmake
/usr/lib32/cmake/Ogg/OggTargets-noconfig.cmake
/usr/lib32/cmake/PulseAudio/PulseAudioConfig.cmake
/usr/lib32/cmake/PulseAudio/PulseAudioConfigVersion.cmake
/usr/lib/CLucene/CLuceneConfig.cmake
/usr/lib/openjpeg-2.3/OpenJPEGConfig.cmake
/usr/lib/openjpeg-2.3/OpenJPEGTargets.cmake
/usr/lib/openjpeg-2.3/OpenJPEGTargets-release.cmake
/usr/local/clang-8/lib/cmake/clang/ClangConfig.cmake
/usr/local/clang-8/lib/cmake/clang/ClangTargets.cmake
/usr/local/clang-8/lib/cmake/clang/ClangTargets-release.cmake
/usr/local/clang-8/lib/cmake/llvm/AddLLVM.cmake
/usr/local/clang-8/lib/cmake/llvm/AddLLVMDefinitions.cmake
/usr/local/clang-8/lib/cmake/llvm/AddOCaml.cmake
/usr/local/clang-8/lib/cmake/llvm/AddSphinxTarget.cmake
/usr/local/clang-8/lib/cmake/llvm/CheckAtomic.cmake
/usr/local/clang-8/lib/cmake/llvm/CheckCompilerVersion.cmake
/usr/local/clang-8/lib/cmake/llvm/CheckLinkerFlag.cmake
/usr/local/clang-8/lib/cmake/llvm/ChooseMSVCCRT.cmake
/usr/local/clang-8/lib/cmake/llvm/CrossCompile.cmake
/usr/local/clang-8/lib/cmake/llvm/DetermineGCCCompatible.cmake
/usr/local/clang-8/lib/cmake/llvm/FindLibpfm.cmake
/usr/local/clang-8/lib/cmake/llvm/FindOCaml.cmake
/usr/local/clang-8/lib/cmake/llvm/FindSphinx.cmake
/usr/local/clang-8/lib/cmake/llvm/GenerateVersionFromCVS.cmake
/usr/local/clang-8/lib/cmake/llvm/GetSVN.cmake
/usr/local/clang-8/lib/cmake/llvm/HandleLLVMOptions.cmake
/usr/local/clang-8/lib/cmake/llvm/HandleLLVMStdlib.cmake
/usr/local/clang-8/lib/cmake/llvm/LLVM-Config.cmake
/usr/local/clang-8/lib/cmake/llvm/LLVMConfig.cmake
/usr/local/clang-8/lib/cmake/llvm/LLVMConfigVersion.cmake
/usr/local/clang-8/lib/cmake/llvm/LLVMExports.cmake
/usr/local/clang-8/lib/cmake/llvm/LLVMExports-release.cmake
/usr/local/clang-8/lib/cmake/llvm/LLVMExternalProjectUtils.cmake
/usr/local/clang-8/lib/cmake/llvm/LLVMInstallSymlink.cmake
/usr/local/clang-8/lib/cmake/llvm/LLVMProcessSources.cmake
/usr/local/clang-8/lib/cmake/llvm/TableGen.cmake
/usr/local/clang-8/lib/cmake/llvm/VersionFromVCS.cmake
/usr/share/doc/gc/README.cmake
/usr/share/graphite2/graphite2.cmake
/usr/share/graphite2/graphite2-release.cmake
There was a problem hiding this comment.
IMO Ableton should really distribute https://github.com/Ableton/link/blob/master/AbletonLinkConfig.cmake or a modified version of it as part of the library so it can be included here. if not, we should turn it into a Find module in cmake_modules and use find_package.
IIUC the goal of these 'system' switches is to allow any platform to use an out-of-source installation of a package, not just Linux. i am able to use SYSTEM_BOOST and SYSTEM_YAMLCPP on macOS. but you've hardcoded the library configuration to Linux here.
there is also the complexity of needing to find and configure the asio standalone library. are you sure this is worth it?
|
I agree. The integration with asio will have to be patched anyways (that's what Debian does and that's also what I can do). That shouldn't be a problem IMHO. Also: Yes, worth it as there will be more things building against those headers. Let me check how I can improve the Arch Linux package to include the .cmake files, then I'll build supercollider again against it. |
|
great, thank you. if Ableton themselves / the other package maintainers are not already doing this, then it will probably be expedient to simply do it ourselves and raise the issue with those package maintainers later. this is an unfortunately neglected aspect of CMake package distribution, which is too bad since it is actually set up to work quite well when everyone acts responsibly. |
|
based on what I'm seeing on Arch Linux, |
|
Yeah, I'm also seeing plenty of |
|
Alright, I have revamped the Hint: I had to fix the paths in |
|
Closing: I think that both Debian and Arch need to ship |
|
a classic example of why names are important! |
|
Ableton sadly doesn't make that super obvious for downstreams. Also, I noticed, that some travis test on macOS got stuck. I can squash and force push to trigger a new build. |
|
after a close reading of the CMake documentation, it will work if you pass no idea why the CI is failing. other people are experiencing it too: https://travis-ci.community/t/macos-build-an-error-occurred-while-generating-the-build-script/7684/5. will probably resolve on its own. |
|
aside from what i just mentioned, this looks good, thank you @dvzrv |
|
Cool! Thanks for yet another round of nerding out about cmake ;-) |
|
For further clarification and reference as abletonlink(!) is packaged all weird in all downstreams currently: When As Debian calls their package |
Adding SYSTEM_ABLETON_LINK (defaults to OFF) option to indicate, that the system version of Ableton Link should be used. lang/CMakeLists.txt: Calling find_package() for AbletonLink with appropriate NAMES. Currently downstreams package AbletonLink as ableton-link and link, which places AbletonLinkConfig.cmake in the wrong paths (e.g. /usr/share/ableton-link and /usr/lib/cmake/link for Debian and Arch respectively). Therefore find_package() for AbletonLink has to be called with appropriate NAMES, so that both the path *and* the file can be resolved. Also, setting REQUIRED, so that cmake will fail generically on not finding AbletonLink.
dvzrv
force-pushed
the
devendor_ableton_link
branch
from
0dfdbd3
to
95bd972
Compare
Purpose and Motivation
This enables package maintainers to use a system version of Ableton Link by specifying
-DSYSTEM_ABLETON_LINK=ONwhen running cmake.This fixes #4818 in a packaging context (because a system version of Ableton Link is preferred over the vendored version).
Types of changes
To-do list