Skip to content
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

[Feature Request] Option to build without libdispatch #17437

Closed
noiseless opened this issue Dec 25, 2021 · 6 comments
Closed

[Feature Request] Option to build without libdispatch #17437

noiseless opened this issue Dec 25, 2021 · 6 comments

Comments

@noiseless
Copy link

noiseless commented Dec 25, 2021

Is your feature request related to a problem?

There is a new mandatory dependency in the tdesktop 3.3.1 release - libdispatch. Now there is no working libdispatch port on *BSD (on FreeBSD and OpenBSD at least), so we have no simple (i.e. without rolling back libdispatch-related commits) way to build actual versions of tdesktop.

Describe the solution you'd like

As far as I know, libdispatch ports for both OpenBSD and FreeBSD are being worked on, but at this point, being able to build a tdesktop without libdispatch seems like a faster solution.

Describe alternatives you've considered

I'm not sure there are any alternative solutions for this problem. They will appear when libdispatch is successfully ported to OpenBSD/FreeBSD.

Additional context

I am willing to help write a patch to be able to build tdesktop without libdispatch if this solution itself is acceptable to you.

@ilya-fedin
Copy link
Contributor

As far as I know, libdispatch ports for both OpenBSD and FreeBSD are being worked on, but at this point, being able to build a tdesktop without libdispatch seems like a faster solution.

Well, maybe this will speedup the porting process. I believe if the option would be added, most maintainers will be just enable the option instead of packaging libdispatch. So it's better if that would be a downstream BSD patch, for the time being at least.

@klemensn
Copy link
Contributor

We can always carry local patches, but with rather big/complicated ports such as tg_owt and tdesktop it quickly becomes a burden and hinders the usual porting/testing effort.

Most of our changes have been submitted via PRs already, the rest is work-in-progress still.

I am less pessimistic about such a new options, especially since dispatch is already ported to Linux and distributions should have less trouble making use of it.

@ilya-fedin
Copy link
Contributor

ilya-fedin commented Dec 26, 2021

It should be enough to specify CXXFLAGS=-DCRL_FORCE_QT (or -DCMAKE_CXX_FLAGS=-DCRL_FORCE_QT) and add a return() just after add_library in external_dispatch's CMakeLists.txt. Then, when dispatch is ported, you can remove this flag and one-line patch.

@ilya-fedin
Copy link
Contributor

I am less pessimistic about such a new options, especially since dispatch is already ported to Linux and distributions should have less trouble making use of it.

I wish this was the true. Some maintainers prefer to disable parts of functionality just because it's using libraries they don't like. So it sometimes feels that it's better to avoid having build options to have less situations when people complaining due to the fact their maintainer disabled that functionality.

@klemensn
Copy link
Contributor

It should be enough to specify CXXFLAGS=-DCRL_FORCE_QT (or -DCMAKE_CXX_FLAGS=-DCRL_FORCE_QT) and add a return() just after add_library in external_dispatch's CMakeLists.txt. Then, when dispatch is ported, you can remove this flag and one-line patch.

Thanks, that seems like the easiest way for now and I just confirmed this works, running 3.3.1 without dispatch on OpenBSD at the moment!

@noiseless
Copy link
Author

Thank you very much for the solution you suggested, it seems to be +/- what we wanted.
Of course, when/if the libdispatch port for OpenBSD is completed, we will prefer to enable it and remove the options/modifications you suggested now.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants