depau/Purism-Calls
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/calls.git synced 2024-11-18 00:25:35 +00:00
Code Issues Releases Wiki Activity
Purism-Calls/plugins/provider/ofono/meson.build

70 lines
1.7 KiB
Meson
Raw Normal View History

Turn providers into plugins courtesy of libpeas This is an initial, static implementation of plugins. The CallsApplication has a plugin name which can be changed with a new --provider command line option. This plugin name is used to instantiate the appropriate plugin when the application is activated. From then on, the plugin cannot change. In future, we can expand this support to include loading multiple plugins at once, configurable through some UI. This will have far-reaching implications though, and complicate things like enumerating the provider hierarchy. There is also no practical benefit right now; the mm and ofono plugins can't be used at the same time because ModemManager and oFono don't play nice together, and the whole raison d'être of the dummy plugin is undermined if you can make use of one of the others. So for now, we just implement one static plugin.
2018-11-23 14:34:41 +00:00
#
# Copyright (C) 2018 Purism SPC
#
# This file is part of Calls.
#
# Calls is free software: you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# Calls is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with Calls. If not, see <http://www.gnu.org/licenses/>.
#
# Author: Bob Ham <bob.ham@puri.sm>
#
# SPDX-License-Identifier: GPL-3.0-or-later
#
subdir('libgdbofono')
Move plugin specific tests into dedicated directory This will prove beneficial when we also add tests for the policy engine plugins. The increased locality is also nice to have.
2022-07-18 20:30:19 +00:00
ofono_install_dir = join_paths(calls_provider_plugin_libdir, 'ofono')
Turn providers into plugins courtesy of libpeas This is an initial, static implementation of plugins. The CallsApplication has a plugin name which can be changed with a new --provider command line option. This plugin name is used to instantiate the appropriate plugin when the application is activated. From then on, the plugin cannot change. In future, we can expand this support to include loading multiple plugins at once, configurable through some UI. This will have far-reaching implications though, and complicate things like enumerating the provider hierarchy. There is also no practical benefit right now; the mm and ofono plugins can't be used at the same time because ModemManager and oFono don't play nice together, and the whole raison d'être of the dummy plugin is undermined if you can make use of one of the others. So for now, we just implement one static plugin.
2018-11-23 14:34:41 +00:00
ofono_plugin = configure_file(
po: Add plugin desktop files Calls preferences will show the name and description of a plugin, so they should be translatable.
2023-01-24 10:50:33 +00:00
input: 'ofono.plugin.in.in',
output: 'ofono.plugin.in',
Turn providers into plugins courtesy of libpeas This is an initial, static implementation of plugins. The CallsApplication has a plugin name which can be changed with a new --provider command line option. This plugin name is used to instantiate the appropriate plugin when the application is activated. From then on, the plugin cannot change. In future, we can expand this support to include loading multiple plugins at once, configurable through some UI. This will have far-reaching implications though, and complicate things like enumerating the provider hierarchy. There is also no practical benefit right now; the mm and ofono plugins can't be used at the same time because ModemManager and oFono don't play nice together, and the whole raison d'être of the dummy plugin is undermined if you can make use of one of the others. So for now, we just implement one static plugin.
2018-11-23 14:34:41 +00:00
configuration: config_data,
po: Add plugin desktop files Calls preferences will show the name and description of a plugin, so they should be translatable.
2023-01-24 10:50:33 +00:00
)
i18n_plugin = i18n.merge_file(
input: ofono_plugin,
output: 'ofono.plugin',
po_dir: po_dir,
type: 'desktop',
build_by_default: true,
build: Install .plugin files Without them we cannot load plugins from the installed location. Closes: #585 Fixes: 42b456f03a3396ca0ba3b27ef8648dae11e80777
2023-06-13 16:53:30 +00:00
install: true,
po: Add plugin desktop files Calls preferences will show the name and description of a plugin, so they should be translatable.
2023-01-24 10:50:33 +00:00
install_dir: ofono_install_dir,
Turn providers into plugins courtesy of libpeas This is an initial, static implementation of plugins. The CallsApplication has a plugin name which can be changed with a new --provider command line option. This plugin name is used to instantiate the appropriate plugin when the application is activated. From then on, the plugin cannot change. In future, we can expand this support to include loading multiple plugins at once, configurable through some UI. This will have far-reaching implications though, and complicate things like enumerating the provider hierarchy. There is also no practical benefit right now; the mm and ofono plugins can't be used at the same time because ModemManager and oFono don't play nice together, and the whole raison d'être of the dummy plugin is undermined if you can make use of one of the others. So for now, we just implement one static plugin.
2018-11-23 14:34:41 +00:00
)
ofono_deps = [
dependency('gobject-2.0'),
meson: Bump gtk dependency to 4.0 Part-of: <https://gitlab.gnome.org/GNOME/calls/-/merge_requests/714>
2023-08-27 01:55:35 +00:00
dependency('gtk4'),
Turn providers into plugins courtesy of libpeas This is an initial, static implementation of plugins. The CallsApplication has a plugin name which can be changed with a new --provider command line option. This plugin name is used to instantiate the appropriate plugin when the application is activated. From then on, the plugin cannot change. In future, we can expand this support to include loading multiple plugins at once, configurable through some UI. This will have far-reaching implications though, and complicate things like enumerating the provider hierarchy. There is also no practical benefit right now; the mm and ofono plugins can't be used at the same time because ModemManager and oFono don't play nice together, and the whole raison d'être of the dummy plugin is undermined if you can make use of one of the others. So for now, we just implement one static plugin.
2018-11-23 14:34:41 +00:00
dependency('libpeas-1.0'),
]
ofono_sources = files(
[
'calls-ofono-call.c', 'calls-ofono-call.h',
'calls-ofono-origin.c', 'calls-ofono-origin.h',
'calls-ofono-provider.c', 'calls-ofono-provider.h'
]
)
plugins: make plugins shared modules again This reverts the main part of commit 4a264252a7a21fc0cab12a29f578379acf267699. As plugins are the prime use case for `shared_module` getting rid of the warning from meson about linking against shared modules weighs less heavy.
2021-04-09 07:23:10 +00:00
calls_ofono = shared_module(
Turn providers into plugins courtesy of libpeas This is an initial, static implementation of plugins. The CallsApplication has a plugin name which can be changed with a new --provider command line option. This plugin name is used to instantiate the appropriate plugin when the application is activated. From then on, the plugin cannot change. In future, we can expand this support to include loading multiple plugins at once, configurable through some UI. This will have far-reaching implications though, and complicate things like enumerating the provider hierarchy. There is also no practical benefit right now; the mm and ofono plugins can't be used at the same time because ModemManager and oFono don't play nice together, and the whole raison d'être of the dummy plugin is undermined if you can make use of one of the others. So for now, we just implement one static plugin.
2018-11-23 14:34:41 +00:00
'ofono',
ofono_sources, gdbofono_headers,
dependencies: ofono_deps,
include_directories: [
src_include,
include_directories('.')
],
build: Avoid building files multiple times We don't have to build each source for every test, instead we could create a static library link it with every test, which will be a lot faster.
2021-05-17 13:21:54 +00:00
link_with: [gdbofono_lib, libcalls],
Turn providers into plugins courtesy of libpeas This is an initial, static implementation of plugins. The CallsApplication has a plugin name which can be changed with a new --provider command line option. This plugin name is used to instantiate the appropriate plugin when the application is activated. From then on, the plugin cannot change. In future, we can expand this support to include loading multiple plugins at once, configurable through some UI. This will have far-reaching implications though, and complicate things like enumerating the provider hierarchy. There is also no practical benefit right now; the mm and ofono plugins can't be used at the same time because ModemManager and oFono don't play nice together, and the whole raison d'être of the dummy plugin is undermined if you can make use of one of the others. So for now, we just implement one static plugin.
2018-11-23 14:34:41 +00:00
install: true,
install_dir: ofono_install_dir
)
Reference in a new issue Copy permalink