Qt6::Multimedia unavailable on some architectures

barak commented 1 year ago

There's a problem with the Debian package, because qt6-multimedia-dev is not available on all architectures. This issue is causing a build failure due to unavailable dependencies on everything except amd64, arm64, armhf, and i386. I've restricted the build to these architectures, but have yet to go through the rigamarole of getting the release managers to allow the package into the upcoming distribution despite this apparent regression.

A better (from my perspective) solution would be to make this build dependency optional, so the library is detected at build time and used iff available. Not sure how hard that would be...

wagenadl commented 1 year ago

Would it be good enough to make it optional at build time? Would that cause the Debian build system to try to get the dependencies? If so, that's an easy fix.

Let's not cause needless regression.

Version 1.5.2 updates the CMakeLists and a few source files to make the QMultiMedia dependency optional.

On 7/28/23 06:10, Barak A. Pearlmutter wrote:

There's a problem with the Debian package, because |qt6-multimedia-dev| is not available on all architectures. This issue is causing a build failure due to unavailable dependencies on everything except |amd64|, |arm64|, |armhf|, and |i386|. I've restricted the build to these architectures, but have yet to go through the rigamarole of getting the release managers to allow the package into the upcoming distribution despite this apparent regression.

A better (from my perspective) solution would be to make this build dependency optional, so the library is detected at build time and used iff available. Not sure how hard that would be...

— Reply to this email directly, view it on GitHub https://github.com/wagenadl/notedeln/issues/13, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACZHS6ZOQPOHHWXOEDMFLZLXSO25JANCNFSM6AAAAAA23PPV2M. You are receiving this because you are subscribed to this thread.Message ID: @.***>

--------------8WWioR5PS0MherSBZK6z9OMk Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Would it be good enough to make it optional at build time? Would that cause the Debian build system to try to get the dependencies? If so, that's an easy fix.

Let's not cause needless regression.

Version 1.5.2 updates the CMakeLists and a few source files to make the QMultiMedia dependency optional.

On 7/28/23 06:10, Barak A. Pearlmutter wrote:

There's a problem with the Debian package, because qt6-multimedia-dev is not available on all architectures. This issue is causing a build failure due to unavailable dependencies on everything except amd64, arm64, armhf, and i386. I've restricted the build to these architectures, but have yet to go through the rigamarole of getting the release managers to allow the package into the upcoming distribution despite this apparent regression.

A better (from my perspective) solution would be to make this build dependency optional, so the library is detected at build time and used iff available. Not sure how hard that would be...

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

--------------8WWioR5PS0MherSBZK6z9OMk--

barak commented 1 year ago

That absolutely solves this. I can put hard dependencies on the library where it's known available, and use a sleazy trick to try to get the autobuild boxes to install it only if available on other architectures.

But ... a very similar issue is cropping up for qt6-webengine-dev which I think is not so easy to use conditionally, since the file Qt6Config.cmake from outside this package requires it to consider Qt6 itself to be available.

  Failed to find required Qt component "WebEngineCore".

so I guess I'll just wait for those architectures to get their act together.

wagenadl commented 1 year ago

Very good.

QtWebEngine is worth considering separately. It is only used by the "webgrab" executable that NotedELN uses to download webpages and convert them to pdf for archiving. Although webgrab has shipped as part of NotedELN since its inception, it could easily be spun off into a separate package. (NotedELN depends on it, but not vice versa, and there are no shared source files.)

With webgrab as a separate package and as an optional dependency, NotedELN could run on architectures where QtWebEngine is not available, even though it could not incorporate downloaded webpages on those architectures. Since NotedELN already handles temporary lack of internet connectivity transparently, for users who switch between architectures, this would mean that webpages that could not be downloaded while on a WE-less architecture would be downloaded once the user access the notebook page on an architecture with WE.

Thoughts?

On 8/2/23 04:04, Barak A. Pearlmutter wrote:

That absolutely solves this. I can put hard dependencies on the library where it's known available, and use a sleazy trick to try to get the autobuild boxes to install it only if available on other architectures.

But ... a very similar issue is cropping up for |qt6-webengine-dev| which I think is not so easy to use conditionally, since the file |Qt6Config.cmake| from outside this package requires it to consider Qt6 itself to be available.

|Failed to find required Qt component "WebEngineCore". |

so I guess I'll just wait for those architectures to get their act together.

— Reply to this email directly, view it on GitHub https://github.com/wagenadl/notedeln/issues/13#issuecomment-1662006784, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACZHS6ZFQB7EH66NVIJG2JLXTIX25ANCNFSM6AAAAAA23PPV2M. You are receiving this because you commented.Message ID: @.***>

--------------qhJioU0WNBkn4LTrIE3nzELv Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Very good.

QtWebEngine is worth considering separately. It is only used by the "webgrab" executable that NotedELN uses to download webpages and convert them to pdf for archiving. Although webgrab has shipped as part of NotedELN since its inception, it could easily be spun off into a separate package. (NotedELN depends on it, but not vice versa, and there are no shared source files.)

With webgrab as a separate package and as an optional dependency, NotedELN could run on architectures where QtWebEngine is not available, even though it could not incorporate downloaded webpages on those architectures. Since NotedELN already handles temporary lack of internet connectivity transparently, for users who switch between architectures, this would mean that webpages that could not be downloaded while on a WE-less architecture would be downloaded once the user access the notebook page on an architecture with WE.

Thoughts?

On 8/2/23 04:04, Barak A. Pearlmutter wrote:

That absolutely solves this. I can put hard dependencies on the library where it's known available, and use a sleazy trick to try to get the autobuild boxes to install it only if available on other architectures.

But ... a very similar issue is cropping up for qt6-webengine-dev which I think is not so easy to use conditionally, since the file Qt6Config.cmake from outside this package requires it to consider Qt6 itself to be available.
  Failed to find required Qt component "WebEngineCore".                                                                                                       
so I guess I'll just wait for those architectures to get their act together.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.

--------------qhJioU0WNBkn4LTrIE3nzELv--

wagenadl commented 4 months ago

Version 1.5.2 make Qt6::Multimedia optional at build time, so NotedELN can at least build and be used on architectures that do not offer Qt6::Multimedia

wagenadl / notedeln

Qt6::Multimedia unavailable on some architectures #13