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
Build: VST3 capable build impossible offline (without Conan) #3474
Comments
|
The error message: vst3sdk doesn't have a system package. It doesn't exist as such. |
|
I have the same issue with the package for Arch Linux. |
|
After hacking around in the cmake setup to somehow make this work with: I get a public/private issue: @LWinterberg @crsib it would be great if this could be addressed, as without a fix for this issue, downstreams will not be able to build audacity 3.2.0. |
|
FTR: Downstreams may provide vst3sdk installed system-wide and it makes sense to provide the option to either target a specific directory or find it via pkg-config (the latter is not supported by upstream because of unknown reasons though). An example of good vst3sdk integration is offered by qtractor. |
|
I am not aware of any Linux distribution that has binary version of vst3sdk. We do not plan to vendor it in any way either. There is a proposed way to use Conan offline. If you are strictly against it I think it is better to build Audacity without vst3 support. |
I'm not asking you to vendor it, but to allow me to build this with an existing version of vst3sdk without having to use conan (that would drag in even more dependencies that I would need to package). It is already packaged for Arch Linux and used in the build process of multiple other packages. |
|
It packages source code, so I don't really know how it is expected to be used. We can provide some sort of FindVST3SDK.cmake, however it will not work with the package from Arch. |
I guess not even steinberg really knows that... ;-) As shown in the patch above it is possible to specify additional
Why is that? I believe specifying what you need to compile from the vst3sdk to integrate into your own software makes a lot of sense, as it does not rely on binary blobs uploaded to some random repository by some random entity :-) |
I disagree with this statement. Conan is as transparent as possible. It builds the SDK from source. More over, we propose offline way to build all missing 3d party libraries from source.
I don't think that a C++ source only package is something very common. AUR usually downloads sources from upstream, not packages it directly. SRPM is also used to build a binary form of the package, not to simply install sources. What you propose is a very strange and fragile form of vendoring - we still need to manually build the SDK within our CMake, the only difference is that the sources are packaged by a distro for some reason.
You miss my point. For FindVST3SDK or pkg-config you need a compiled package to be already installed somehow on the system. VST3 SDK is not a header only library, it must be built before it is used. I will check on Monday, but I do not expect that making a proper VST3DSK package for Arch will be easy, if possible at all. Probably you can add SDK as a separate source bundle and install it into some temp location in PKGBuild before building Audacity though. |
|
(Almost) Every other app I have seen using the VST3SDK on linux either had it as a git submodule, had an option to specify the path to the SDK, or did vendor it. How do you build offline with conan? I haven't seen anywhere how to do it. So far Conan has made the process more difficult for the Flatpak, disabling it is the simplest way. |
Then where do you define which version of vst3sdk it downloads from where and builds with which options?
I'm packaging for the official repositories. This has nothing to do with the AUR.
I don't think FindVST3SDK would be a good solution to this problem, but rather offering an option to provide the location to the SDK and handpicking the files one needs (this is already done in includes, why not for the .cpp files?) and adding them to the sources in the cmake setup. The cmake "integration" provided by steinberg has been lacking and it does not offer a clear separation between build and test. Additionally it does not offer any form of installation target so it is completely unclear what would even be the consumable output of using their top-level CMakeLists.txt. When building the sdk just on its own it only outputs the static libraries, if building the examples: Without building the examples these static libraries do not exist and they would also never be installed as they do not have an install target. The problem with building vst3sdk using its cmake setup in the context of another project is, that it takes very long (recursive clone takes a lot of space because of docs), is brittle as a build (by default the dummy plugins are dragged in and their build failed on me several times already). Doing this by default would make builds requiring vst3sdk take much longer and would also end up being more brittle (if done using default build configuration). This concludes: It would be much more transparent and sane to rely on the files from the SDK that are actually needed and build with them.
As mentioned above, this is what the vst3sdk package does: We copy the required headers and source files from the upstream source tarball and then provide a pkg-config integration (as upstream does not do that). We do not provide any of the static libs as it is unclear how they would be used as consumables for something else. |
|
is building without vst3 an option? VST3 SDK still has licensing issues, for which Fedora/Red Hat are refusing to package it. |
|
|
|
BTW a |
afaik that would only work for vst3 sdk copies, as in full source. |
|
From what I understand the following libraries (i.e. Lines 1227 to 1230 in 482e0aa
In the current build system setup there is no alternative to using conan for that. The respective sources however could also be built in the context of the private sources ( Line 86 in 482e0aa
|
which is what "we" want (it's IMHO the simplest solution), it then would be added as a cmake subproject (that's what other do, no idea how to actually do it, it is CMake) |
This is definitely not an option.
We will see what can be done here.
The recipes are transparent and introspectable. For example, using |
|
@dvzrv is there a reason why you package everything but Otherwise I am mostly ready to open a PR that allows to build without Conan, but only if full vst3sdk is present, which is not the case for the Arch Linux package. |
|
@crsib None of the packages so far required the CMakeLists.txt file. That's basically the only reason why it is not included. However, I can change that in an update. Would your change also require the *.cmake files that steinberg ships alongside? |
|
Is there a reason to strip the SDK? If there is one, we can make Arch specific hackaround, but it will break at some point surely. Probably not in the mid-term though. |
|
So which commits are relevant? |
Seems to be the stuff in #3703 |
|
ah yeah, I missed it. thanks! |
hfiguiere commentedAug 30, 2022
Bug description
I don't have Conan as the build is done offline.
Steps to reproduce
-Daudacity_conan_enabled=OffExpected behavior
That I can pass a documented flag to CMake to tell it were to find the VST3SDK
Actual behavior
Nothing. I tries to detect things with black magic
Audacity Version
latest beta
Operating system
Linux
Additional context
QA: This is a build problem.
The text was updated successfully, but these errors were encountered: