-
-
Notifications
You must be signed in to change notification settings - Fork 992
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
Use vcpkg for Linux CI #7316
base: master
Are you sure you want to change the base?
Use vcpkg for Linux CI #7316
Conversation
@DomClark Do you have any ideas why the Linux build is failing on the Configure step now?
|
Restoring the cache will create the Edit: according to the documentation, CMake will create the build directory if it doesn't exist, so you should be able to omit |
@DomClark Thanks, that did the trick |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Two general thoughts about this:
|
I will always advocate against a container-first build in the LMMS project the additional complexity it adds to the environment has not been well-justified. Lukas set this up and when I reached out to him privately about this in 2020, this is what he said:
In my experience, troubleshooting build issues in a container are about twice as hard as build issues in an interactive VM or on a native machine so they must be weighed against the complexity to setup a build environment. In the case of LMMS, our AppImage requirement is an LTS Linux version, so this makes compiling these dependencies by hand -- e.g. vcpkg -- more attractive for features, libraries or versions of libraries that aren't available through the LTS Linux package manager. I don't believe I would recommend this technique to newcomers, but if we DO eventually start to recommend new developers to use vcpkg, it may make sense to find a way to re-use the ccache or a container for this to speed-up build times.
I think you mean "How can I
The dependencies are listed here: https://github.com/LMMS/lmms/wiki/Compiling#libraries. If this isn't being maintained, we should probably replace it with a link to the appropriate build file. Whether we keep them around should depend on those that prefer them to interactive VMs or native builds and how willing they are to continue helping maintain them. |
I could update our Docker image so that it mirrors the same vcpkg + apt setup from this PR. That way people who use Docker and want it for their local builds can continue using it and have all of vcpkg's up-to-date dependencies. @tresf One big concern I have about this PR is the cache size. We have to install a lot of APT packages and some of them take up a lot of disk space. The total cache size for the APT packages is 2.3 GB which is huge. And the cache size for the vcpkg packages is ~193 MB. We are already running low of cache space and this would only make it worse. One potential solution is to update our Linux Docker image to use vcpkg and all of the same dependencies as this PR. This would require a copy of Yes, this would mean going back to using a custom Docker image, BUT we should be able to switch back to plain What do you think? |
I removed caching of the system packages since they were contributing the most to the high cache usage. |
This PR moves the Linux CI builds away from our custom Ubuntu 20.04 images to a plain Ubuntu 20.04 runner with vcpkg.
deps-ubuntu-20.04-gcc.txt
as a living document of (almost) all required system dependenciesQt
: 5.12.8 --> 5.15.2 (all CI builds use 5.15.x now)libsndfile
: 1.0.28 --> 1.2.2 (enables opus and mp3 support)fluidsynth
: 2.1.1 --> 2.3.5libsamplerate
: 0.1.9 --> 0.2.2qt5-x11embed
submodule to fix deprecation warning which was treated as an error (Avoid deprecated QFlags constructor lukas-w/qt5-x11embed#6)I will try to do MinGW builds with vcpkg next.