use Windows dependencies from vcpkg #3594
Conversation
Be-ing
force-pushed
the
vcpkg_deps
branch
4 times, most recently
from
63cddc5 to
5660e1e
Compare
There was a problem hiding this comment.
Can we target this for 2.4? I am not feeling comfortable to change all dependency now just for a release.
We have enough open Windows related bugs. https://launchpad.net/mixxx/+milestone/2.3.0
And are still fighting to get the cmake settings for MSVC build right.
We don't know what will happens with this. Only in the best case it will have no regressions.
What is missing in the 2.3-j00019-PLATFORM-CONFIGURATION-static-55e94982-minimal
|
No. We did not just spend a month of work to not use this for 2.3. Making a release with an unreproducible and unmaintainable set of dependencies is a bad idea. So is having some features not available on some OSes but not others. |
libkeyfinder and libdjinterop, Qt 5.15 LTS |
|
Updating to a new QT version just before a release for no reason is a bad idea. Lib libkeyfinder and libdjinterop are added as source code to the download folder, right. This should work independent in the same way as on our other targets. |
|
We cannot simply download libkeyfinder at build time. It depends on fftw which is not in the old build environment. |
|
OK, but we can either download the fftw source as well or use the binaries from a vckg that contains only that. |
|
That would be overcomplicated and make it hard for contributors building locally. |
Be-ing
force-pushed
the
vcpkg_deps
branch
2 times, most recently
from
e3c6db2 to
cf5a5ea
Compare
Also Lilv and libmodplug, which are currently missing. |
|
Build succeeded but DLLs are missing. |
Be-ing
force-pushed
the
vcpkg_deps
branch
5 times, most recently
from
820c226 to
bd84d50
Compare
|
It works!!! 🎉 🎉 🎉 |
|
So... is anyone going to press merge? |
|
This will break broadcasting. We have the following options,
|
As long as we need this on Linux anyway, I'd prefer that. |
|
Please merge 2.3 to check if the internal libshout 2.4.1 is selected now. |
|
The internal libshout does not build with windows currently. I have made libshout-idjc 2.4.1 usable with windows. That can be found here: Alternative we can pick the libshout.lib from the existing build environment. |
|
I'm not very comfortable rushing libshout-idj at the last minute. @daschuer can you fork https://github.com/Be-ing/icecast-libshout/tree/msvc apply the bug fix and make a pull request to our vcpkg fork to use your fix? |
|
No, please use libshout 2.4.1 for Mixxx 2.3. As I mentioned earlier, I prefer to not update all libraries at this time in our release process. So let's consider to retarget this PR to 2.4. |
|
IIUC going back to libshout 2.4.1 will require a bit of work to get it building with CMake. I don't know if this would be any more or less work than fixing 2.4.5. I'm not going in circles repeating why delaying this until 2.4 is a bad idea. |
|
I'm pretty tired of dealing with this badly maintained libshout library whose maintainers don't care about our needs. |
Why not? Can you please get it building on Windows? I'd appreciate if someone who actually uses this feature takes responsibility for maintaining it. @Holzhaus and I have already put a month of work into getting vcpkg working. Neither of us use libshout and now we are told it is entirely broken and upstream has been entirely broken for 5 years?!?! And upstream ignores their issue tracker, has no infrastructure for submitting code changes, requires using a legacy chat system to get any contact with maintainers, and won't accept CMake support?! This affects the macOS builds too because the macOS environment uses libshout 2.4.4. So I think we should unconditionally use our internal fork of libshout 2.4.1. |
|
Does the internal libshout 2.4.1 fork build on all platforms? Then let's use it and not waste any time and efforts. |
|
I gave it a try and it didn't build on macOS. Someone else take care of this hot garbage library. |
Neither @Holzhaus nor I use Windows and we spent a month working on Windows support using VMs and GitHub Actions. You can get libshout building on Windows if you care about this feature. |
|
I would go with libschout-idjc 2.4.1. It has some patches that have been integrated upstream in the mean time. I don't see a need to do more work and watch again the GitHub Workflow hourglass for hours. We can disable the HE-AAC part if you think that is required, but since this is already a preference option not available by default, because we don't ship the library, it can remain IMHO. |
|
Okay, let's go with that then. I am unsure about the legality of shipping binaries with an AAC encoder so I'd prefer to disable that feature. |
|
I can prepare a branch for that. |
|
I need to disable AAC on RPMFusion as already discussed! Otherwise we would no longer qualify for the free repositories. |
|
@uklotzde are you sure? I thought RPMFusion could ship code with free copyright licenses that had patent issues. |
|
|
Closing in favor of #3615 with libshout-idjc |
No description provided.