mirrors/pipewire
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/pipewire/pipewire.git synced 2025-11-03 09:01:54 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions
pipewire/src/modules/meson.build

282 lines
9.7 KiB
Meson
Raw Normal View History

pinos -> pipewire
2017-05-23 19:15:33 +02:00
subdir('spa')
pipewire_module_c_args = [
'-DHAVE_CONFIG_H',
'-D_GNU_SOURCE',
]
module-access: make new access module Rename the flatpak module to access module. The access module should either let the client connect or mask the client busy while the permissions are being configured. It is then up to the session manager to collect the right permissions of the objects and configure those in the client. Let the media session monitor the clients and configure the permissions.
2018-10-27 17:33:21 +01:00
pipewire_module_access = shared_library('pipewire-module-access', [ 'module-access.c' ],
pinos -> pipewire
2017-05-23 19:15:33 +02:00
c_args : pipewire_module_c_args,
include_directories : [configinc, spa_inc],
install : true,
install_dir : modules_install_dir,
meson: add rpath on the modules_install_dir for all modules Otherwise the dynamic loader won't be able to find libraries in modules_install_dir we link against fixes #214
2020-03-08 09:38:20 +01:00
install_rpath: modules_install_dir,
module-access: make new access module Rename the flatpak module to access module. The access module should either let the client connect or mask the client busy while the permissions are being configured. It is then up to the session manager to collect the right permissions of the objects and configure those in the client. Let the media session monitor the clients and configure the permissions.
2018-10-27 17:33:21 +01:00
dependencies : [mathlib, dl_lib, pipewire_dep],
modules: add module-loopback Add a new loopback module that can also create virtual-sink and virtual-source.
2021-04-22 13:08:20 +02:00
)
modules: set right library variable
2021-04-26 10:45:44 +02:00
pipewire_module_loopback = shared_library('pipewire-module-loopback',
modules: add module-loopback Add a new loopback module that can also create virtual-sink and virtual-source.
2021-04-22 13:08:20 +02:00
[ 'module-loopback.c' ],
c_args : pipewire_module_c_args,
include_directories : [configinc, spa_inc],
install : true,
install_dir : modules_install_dir,
install_rpath: modules_install_dir,
dependencies : [mathlib, dl_lib, pipewire_dep],
pinos -> pipewire
2017-05-23 19:15:33 +02:00
)
module-filter-chain: rename This does not have to be ladspa specific so rename it.
2021-05-04 15:30:01 +02:00
pipewire_module_filter_chain = shared_library('pipewire-module-filter-chain',
filter-chain: add biquads to filter-chain Add some biquad filters to the builtin filters. Add an example 6 band equalizer sink filter chain.
2021-05-10 18:09:55 +02:00
[ 'module-filter-chain.c',
'module-filter-chain/biquad.c' ],
modules: add begining of ladspa filter Can be used to build chains or sink/source.
2021-04-30 10:52:25 +02:00
c_args : pipewire_module_c_args,
include_directories : [configinc, spa_inc],
install : true,
install_dir : modules_install_dir,
install_rpath: modules_install_dir,
dependencies : [mathlib, dl_lib, pipewire_dep],
)
Add echo-cancel module Only implement the null echo cancel implementation for now. And skeleton webrtc echo cancel implementation It uses 4 streams arranged as: input ---+---> source ^ | sink ---+---> output The output of the source is the filtered input of the input stream (linked a master source) based on the data going from sink to the output (linked to a master sink). All streams are arranged in the same group so that the echo canceler does not have to deal with clock drift. For echo cancelers that can handle clock drift we might want place the source and sink chains in different groups.
2021-04-26 10:47:02 +02:00
pipewire_module_echo_cancel = shared_library('pipewire-module-echo-cancel',
[ 'module-echo-cancel.c',
'module-echo-cancel/aec-null.c',
'module-echo-cancel/aec-webrtc.cc' ],
c_args : pipewire_module_c_args,
include_directories : [configinc, spa_inc],
install : true,
install_dir : modules_install_dir,
install_rpath: modules_install_dir,
dependencies : [mathlib, dl_lib, pipewire_dep],
)
pw-profiler: add profiler tool Add Profiler object and fields. Add profiler extension API. It notifies Profiler objects with real-time performance data. Add module that implements the profiler extension. Add pw-profiler tool that binds to the profiler API and dumps the data into a log file, gnuplot files, a html page and a script to generate svg graphs. This is almost the same as what JACK2 JackEngineProfiling does.
2020-01-31 15:07:26 +01:00
pipewire_module_profiler = shared_library('pipewire-module-profiler',
[ 'module-profiler.c',
'module-profiler/protocol-native.c', ],
c_args : pipewire_module_c_args,
include_directories : [configinc, spa_inc],
install : true,
install_dir : modules_install_dir,
meson: add rpath on the modules_install_dir for all modules Otherwise the dynamic loader won't be able to find libraries in modules_install_dir we link against fixes #214
2020-03-08 09:38:20 +01:00
install_rpath: modules_install_dir,
pw-profiler: add profiler tool Add Profiler object and fields. Add profiler extension API. It notifies Profiler objects with real-time performance data. Add module that implements the profiler extension. Add pw-profiler tool that binds to the profiler API and dumps the data into a log file, gnuplot files, a html page and a script to generate svg graphs. This is almost the same as what JACK2 JackEngineProfiling does.
2020-01-31 15:07:26 +01:00
dependencies : [mathlib, dl_lib, pipewire_dep],
)
module-access: make new access module Rename the flatpak module to access module. The access module should either let the client connect or mask the client busy while the permissions are being configured. It is then up to the session manager to collect the right permissions of the objects and configure those in the client. Let the media session monitor the clients and configure the permissions.
2018-10-27 17:33:21 +01:00
if dbus_dep.found()
dbus: move rtkit to module Move the rtkit code to a module. Make sure we don't need to include the dbus headers in the spa dbus interface. This removes the dependency on dbus.
2018-02-08 10:02:17 +01:00
pipewire_module_rtkit = shared_library('pipewire-module-rtkit', [ 'module-rtkit.c' ],
c_args : pipewire_module_c_args,
add portal module again This access module now only checks if the connection is comming from the portal and tags the ACCESS property with portal in that case. It will no longer do permission store checks, that's for the session manager.
2020-07-17 14:12:10 +02:00
include_directories : [configinc, spa_inc],
install : true,
install_dir : modules_install_dir,
install_rpath: modules_install_dir,
dependencies : [dbus_dep, mathlib, dl_lib, pipewire_dep],
)
pipewire_module_portal = shared_library('pipewire-module-portal', [ 'module-portal.c' ],
c_args : pipewire_module_c_args,
portal: add portal module again Add this again for now until we can integrate this into the session manager somehow.
2020-05-18 16:30:09 +02:00
include_directories : [configinc, spa_inc],
install : true,
install_dir : modules_install_dir,
install_rpath: modules_install_dir,
dependencies : [dbus_dep, mathlib, dl_lib, pipewire_dep],
)
dbus: move rtkit to module Move the rtkit code to a module. Make sure we don't need to include the dbus headers in the spa dbus interface. This removes the dependency on dbus.
2018-02-08 10:02:17 +01:00
endif
client-device: add client device Make it possible to implement a device out-of-process
2019-05-28 14:04:58 +02:00
pipewire_module_client_node = shared_library('pipewire-module-client-device',
[ 'module-client-device.c',
'module-client-device/resource-device.c',
'module-client-device/proxy-device.c',
'module-client-device/protocol-native.c', ],
c_args : pipewire_module_c_args,
include_directories : [configinc, spa_inc],
install : true,
install_dir : modules_install_dir,
meson: add rpath on the modules_install_dir for all modules Otherwise the dynamic loader won't be able to find libraries in modules_install_dir we link against fixes #214
2020-03-08 09:38:20 +01:00
install_rpath: modules_install_dir,
client-device: add client device Make it possible to implement a device out-of-process
2019-05-28 14:04:58 +02:00
dependencies : [mathlib, dl_lib, pipewire_dep],
)
core: remove create-link Make a link factory and use create-object to make links. That way we can have different kinds of links based on the factory and we can also hide the factory when link creation should be blocked.
2018-01-16 16:53:08 +01:00
pipewire_module_link_factory = shared_library('pipewire-module-link-factory',
[ 'module-link-factory.c' ],
c_args : pipewire_module_c_args,
include_directories : [configinc, spa_inc],
install : true,
install_dir : modules_install_dir,
meson: add rpath on the modules_install_dir for all modules Otherwise the dynamic loader won't be able to find libraries in modules_install_dir we link against fixes #214
2020-03-08 09:38:20 +01:00
install_rpath: modules_install_dir,
core: remove create-link Make a link factory and use create-object to make links. That way we can have different kinds of links based on the factory and we can also hide the factory when link creation should be blocked.
2018-01-16 16:53:08 +01:00
dependencies : [mathlib, dl_lib, pipewire_dep],
)
pulse-server: improve stale socket detection Only declare stale when ECONNREFUSED and not socket activated.
2020-11-12 13:02:18 +01:00
pipewire_module_protocol_deps = [mathlib, dl_lib, pipewire_dep]
meson: don't add systemd_dep to dependencies if systemd option is false.
2018-11-22 18:07:53 -02:00
meson: Use `feature` options everywhere it makes sense
2021-03-10 15:36:27 -03:00
if systemd_dep.found()
pulse-server: improve stale socket detection Only declare stale when ECONNREFUSED and not socket activated.
2020-11-12 13:02:18 +01:00
pipewire_module_protocol_deps += systemd_dep
meson: don't add systemd_dep to dependencies if systemd option is false.
2018-11-22 18:07:53 -02:00
endif
Make extensions Make the protocol-native and client-node extensions
2017-06-21 12:11:54 +02:00
pipewire_module_protocol_native = shared_library('pipewire-module-protocol-native',
[ 'module-protocol-native.c',
protocol: make connect async Make the protocol client connect call async with a callback when it completes. Move the connect methods into separate files, add an empty connect method that will use the screencast portal to get a pipewire fd. Use the remote intention to get the connect method. Add some better error reporting.
2018-01-30 15:11:39 +01:00
'module-protocol-native/local-socket.c',
'module-protocol-native/portal-screencast.c',
Make extensions Make the protocol-native and client-node extensions
2017-06-21 12:11:54 +02:00
'module-protocol-native/protocol-native.c',
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
'module-protocol-native/v0/protocol-native.c',
Work on unifying client and server Remove context and extensions, make client API also use the core. Make a new pw_remote object that keeps connections with remote instances. Remove introspection API, it's just as easy to connect to the registry and get updates like that. Expand the protocol a little to make it useful for making listeners and connections. Move protocol specific connection to the module. Make some new convenience methods. Make a factory to create nodes from spa objects Add an example of a local pipeline displaying a v4l2 source.
2017-07-11 12:24:03 +02:00
'module-protocol-native/connection.c' ],
pinos -> pipewire
2017-05-23 19:15:33 +02:00
c_args : pipewire_module_c_args,
include_directories : [configinc, spa_inc],
install : true,
install_dir : modules_install_dir,
meson: add rpath on the modules_install_dir for all modules Otherwise the dynamic loader won't be able to find libraries in modules_install_dir we link against fixes #214
2020-03-08 09:38:20 +01:00
install_rpath: modules_install_dir,
pulse-server: improve stale socket detection Only declare stale when ECONNREFUSED and not socket activated.
2020-11-12 13:02:18 +01:00
dependencies : pipewire_module_protocol_deps,
pinos -> pipewire
2017-05-23 19:15:33 +02:00
)
pulse-server: request dbus name Request the org.pulseaudio.Server dbus name. This makes gnome-shell reconnect automatically.
2020-11-20 11:52:57 +01:00
pipewire_module_protocol_pulse_deps = pipewire_module_protocol_deps
if dbus_dep.found()
pipewire_module_protocol_pulse_deps += dbus_dep
endif
pulse: move pulse protocol to module
2020-10-08 11:57:35 +02:00
pipewire_module_protocol_pulse = shared_library('pipewire-module-protocol-pulse',
[ 'module-protocol-pulse.c',
pulse-server: Factor out module code to compile independently This starts breaking up the giant monolith that is the pulse-server.c code into more manageable chunks by trying to split the module code into individual compilation units.
2021-04-15 15:53:05 -04:00
'module-protocol-pulse/manager.c',
pulse-server: add introspection of clients and modules Add manager object to collect object info Wait for object info until completing client connect Implement clients and modules list and info.
2020-10-25 15:28:42 +01:00
'module-protocol-pulse/pulse-server.c',
pulse-server: add ladspa sink and source To make an rnnoise filtered source: pactl load-module module-ladspa-source source_name=rnnoise_mic label=noise_suppressor_mono plugin=/usr/lib64/ladspa/ladspa/librnnoise_ladspa.so To make an equalizer sink: pactl load-module module-ladspa-sink sink_name=eq_out label=mbeq plugin=/usr/lib64/ladspa/mbeq_1197.so
2021-05-09 20:02:02 +02:00
'module-protocol-pulse/modules/module-ladspa-sink.c',
'module-protocol-pulse/modules/module-ladspa-source.c',
pulse-server: Factor out module code to compile independently This starts breaking up the giant monolith that is the pulse-server.c code into more manageable chunks by trying to split the module code into individual compilation units.
2021-04-15 15:53:05 -04:00
'module-protocol-pulse/modules/module-loopback.c',
'module-protocol-pulse/modules/module-native-protocol-tcp.c',
'module-protocol-pulse/modules/module-null-sink.c',
pulse-server: implement module-tunnel-sink/source See #865
2021-05-12 17:00:45 +02:00
'module-protocol-pulse/modules/module-pipe-sink.c',
pulse-server: add remap sink and source modules
2021-04-22 20:44:06 +02:00
'module-protocol-pulse/modules/module-remap-sink.c',
'module-protocol-pulse/modules/module-remap-source.c',
pulse-server: Factor out module code to compile independently This starts breaking up the giant monolith that is the pulse-server.c code into more manageable chunks by trying to split the module code into individual compilation units.
2021-04-15 15:53:05 -04:00
'module-protocol-pulse/modules/module-simple-protocol-tcp.c',
pulse-server: implement module-tunnel-sink/source See #865
2021-05-12 17:00:45 +02:00
'module-protocol-pulse/modules/module-tunnel-sink.c',
'module-protocol-pulse/modules/module-tunnel-source.c',
pipewire-pulse: add zeroconf module
2021-05-14 11:39:44 +02:00
'module-protocol-pulse/modules/module-zeroconf-discover.c',
pulse-server: Factor out module code to compile independently This starts breaking up the giant monolith that is the pulse-server.c code into more manageable chunks by trying to split the module code into individual compilation units.
2021-04-15 15:53:05 -04:00
],
pulse: move pulse protocol to module
2020-10-08 11:57:35 +02:00
c_args : pipewire_module_c_args,
include_directories : [configinc, spa_inc],
install : true,
install_dir : modules_install_dir,
install_rpath: modules_install_dir,
pulse-server: request dbus name Request the org.pulseaudio.Server dbus name. This makes gnome-shell reconnect automatically.
2020-11-20 11:52:57 +01:00
dependencies : pipewire_module_protocol_pulse_deps,
pulse: move pulse protocol to module
2020-10-08 11:57:35 +02:00
)
module-pulse-tunner: add module to tunnel to PulseAudio Add a module that can make a source or sink that tunnels audio to or from a (remote) PulseAudio server.
2021-05-12 15:55:15 +02:00
if pulseaudio_dep.found()
pipewire_module_pulse_tunnel = shared_library('pipewire-module-pulse-tunnel',
[ 'module-pulse-tunnel.c' ],
c_args : pipewire_module_c_args,
include_directories : [configinc, spa_inc],
install : true,
install_dir : modules_install_dir,
install_rpath: modules_install_dir,
dependencies : [mathlib, dl_lib, pipewire_dep, pulseaudio_dep],
)
endif
Add simple protocol The simple protocol listens on a socket, creates a new pw_client for each connected client and reads/writes raw audio bytes on the socket. Incomming bytes are copied to a playback stream, outgoing bytes are copied from a capture pw_stream. Fixes #954
2021-04-12 09:33:41 +02:00
pipewire_module_protocol_simple = shared_library('pipewire-module-protocol-simple',
[ 'module-protocol-simple.c' ],
c_args : pipewire_module_c_args,
include_directories : [configinc, spa_inc],
install : true,
install_dir : modules_install_dir,
install_rpath: modules_install_dir,
dependencies : pipewire_module_protocol_deps,
)
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
pipewire_module_client_node = shared_library('pipewire-module-client-node',
[ 'module-client-node.c',
'module-client-node/remote-node.c',
'module-client-node/client-node.c',
'module-client-node/protocol-native.c',
'module-client-node/v0/client-node.c',
'module-client-node/v0/transport.c',
'module-client-node/v0/protocol-native.c',
'spa/spa-node.c', ],
c_args : pipewire_module_c_args,
metadata: Add metadata API Metadata allows apps to attach properties to objects that can be read by other apps. Not complete yet, properties should be removed when the object is removed.
2019-11-03 10:31:14 +01:00
include_directories : [configinc, spa_inc],
link_with : pipewire_module_protocol_native,
install : true,
install_dir : modules_install_dir,
meson: add rpath on the modules_install_dir for all modules Otherwise the dynamic loader won't be able to find libraries in modules_install_dir we link against fixes #214
2020-03-08 09:38:20 +01:00
install_rpath: modules_install_dir,
metadata: Add metadata API Metadata allows apps to attach properties to objects that can be read by other apps. Not complete yet, properties should be removed when the object is removed.
2019-11-03 10:31:14 +01:00
dependencies : [mathlib, dl_lib, pipewire_dep],
)
pipewire_module_metadata = shared_library('pipewire-module-metadata',
[ 'module-metadata.c',
'module-metadata/proxy-metadata.c',
'module-metadata/metadata.c',
'module-metadata/protocol-native.c'],
c_args : pipewire_module_c_args,
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
include_directories : [configinc, spa_inc],
link_with : pipewire_module_protocol_native,
install : true,
install_dir : modules_install_dir,
meson: add rpath on the modules_install_dir for all modules Otherwise the dynamic loader won't be able to find libraries in modules_install_dir we link against fixes #214
2020-03-08 09:38:20 +01:00
install_rpath: modules_install_dir,
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
dependencies : [mathlib, dl_lib, pipewire_dep],
)
connection: add test and fix a bug Add a unit test for the connection When we consumed all packets in a buffer, try to get more data instead of failing right away.
2019-03-19 11:44:23 +01:00
test('pw-test-protocol-native',
executable('pw-test-protocol-native',
[ 'module-protocol-native/test-connection.c',
'module-protocol-native/connection.c' ],
c_args : libpipewire_c_args,
include_directories : [configinc, spa_inc ],
dependencies : [pipewire_dep],
Optionally install examples and tests This makes it easier to test PipeWire in its "as-installed" state, for example in an OS distribution. The .test metadata files in ${datadir}/installed-tests/${package} are a convention taken from GNOME's installed-tests initiative, allowing a generic test-runner like gnome-desktop-testing to discover and run tests in an automatic way. The installation path ${libexecdir}/installed-tests/${package} is also a convention borrowed from GNOME's installed-tests initiative. In addition to the automated tests, I've installed example executables in the same place, for manual testing. They could be separated into a different directory if desired, but they seem like they have more similarities with the automated tests than differences: both are there to test that PipeWire works correctly, and neither should be relied on for production use. Some examples are installed in deeper subdirectories to avoid name clashes. Signed-off-by: Simon McVittie <smcv@debian.org>
2020-06-05 14:06:36 +01:00
install : installed_tests_enabled,
install_dir : installed_tests_execdir),
connection: add more test
2019-03-19 11:58:46 +01:00
env : [
'SPA_PLUGIN_DIR=@0@/spa/plugins/'.format(meson.build_root()),
Fix tests, use the right config dir
2021-02-11 21:14:43 +01:00
'PIPEWIRE_CONFIG_DIR=@0@/src/daemon/'.format(meson.build_root()),
connection: add more test
2019-03-19 11:58:46 +01:00
'PIPEWIRE_MODULE_DIR=@0@/src/modules/'.format(meson.build_root())
])
connection: add test and fix a bug Add a unit test for the connection When we consumed all packets in a buffer, try to get more data instead of failing right away.
2019-03-19 11:44:23 +01:00
Optionally install examples and tests This makes it easier to test PipeWire in its "as-installed" state, for example in an OS distribution. The .test metadata files in ${datadir}/installed-tests/${package} are a convention taken from GNOME's installed-tests initiative, allowing a generic test-runner like gnome-desktop-testing to discover and run tests in an automatic way. The installation path ${libexecdir}/installed-tests/${package} is also a convention borrowed from GNOME's installed-tests initiative. In addition to the automated tests, I've installed example executables in the same place, for manual testing. They could be separated into a different directory if desired, but they seem like they have more similarities with the automated tests than differences: both are there to test that PipeWire works correctly, and neither should be relied on for production use. Some examples are installed in deeper subdirectories to avoid name clashes. Signed-off-by: Simon McVittie <smcv@debian.org>
2020-06-05 14:06:36 +01:00
if installed_tests_enabled
test_conf = configuration_data()
meson: replace join_paths(a, b) with a / b More readable and from the meson reference manual: (since 0.49.0) Using the/ operator on strings is equivalent to calling join_paths.
2021-04-15 14:41:04 +10:00
test_conf.set('exec', installed_tests_execdir / 'pw-test-protocol-native')
Optionally install examples and tests This makes it easier to test PipeWire in its "as-installed" state, for example in an OS distribution. The .test metadata files in ${datadir}/installed-tests/${package} are a convention taken from GNOME's installed-tests initiative, allowing a generic test-runner like gnome-desktop-testing to discover and run tests in an automatic way. The installation path ${libexecdir}/installed-tests/${package} is also a convention borrowed from GNOME's installed-tests initiative. In addition to the automated tests, I've installed example executables in the same place, for manual testing. They could be separated into a different directory if desired, but they seem like they have more similarities with the automated tests than differences: both are there to test that PipeWire works correctly, and neither should be relied on for production use. Some examples are installed in deeper subdirectories to avoid name clashes. Signed-off-by: Simon McVittie <smcv@debian.org>
2020-06-05 14:06:36 +01:00
configure_file(
input: installed_tests_template,
output: 'pw-test-protocol-native.test',
install_dir: installed_tests_metadir,
configuration: test_conf
)
endif
adapter: add adapter node An adapter is like an audio-dsp node and client-stream combined. It allows tighter control with the device (for rate control and variable buffer sizes), software volume. The idea is to also implement the client-stream with this eventually.
2019-07-02 17:34:26 +02:00
pipewire_module_adapter = shared_library('pipewire-module-adapter',
[ 'module-adapter.c',
'module-adapter/adapter.c',
'spa/spa-node.c' ],
c_args : pipewire_module_c_args,
include_directories : [configinc, spa_inc],
install : true,
install_dir : modules_install_dir,
meson: add rpath on the modules_install_dir for all modules Otherwise the dynamic loader won't be able to find libraries in modules_install_dir we link against fixes #214
2020-03-08 09:38:20 +01:00
install_rpath: modules_install_dir,
adapter: add adapter node An adapter is like an audio-dsp node and client-stream combined. It allows tighter control with the device (for rate control and variable buffer sizes), software volume. The idea is to also implement the client-stream with this eventually.
2019-07-02 17:34:26 +02:00
dependencies : [mathlib, dl_lib, rt_lib, pipewire_dep],
)
extensions: implement new session manager extension This extension, implemented in module-session-manager, implements a set of objects that are useful for session managers.
2019-05-23 18:59:05 +03:00
pipewire_module_session_manager = shared_library('pipewire-module-session-manager',
[ 'module-session-manager.c',
session-manager: move files into client-endpoint / client-session subdirs To clean up space for the new implementation. The existing code is exclusively for use with the client-endpoint and client-session factories.
2020-03-24 12:25:13 +02:00
'module-session-manager/client-endpoint/client-endpoint.c',
'module-session-manager/client-endpoint/endpoint-stream.c',
'module-session-manager/client-endpoint/endpoint.c',
'module-session-manager/client-session/client-session.c',
'module-session-manager/client-session/endpoint-link.c',
'module-session-manager/client-session/session.c',
session-manager: implement factories for session, endpoint-stream & endpoint-link Heavily based on the endpoint factory
2020-03-26 14:02:56 +02:00
'module-session-manager/endpoint-link.c',
'module-session-manager/endpoint-stream.c',
session-manager: implement 'endpoint' factory This is modeled after the 'metadata' factory and provides a way to use the pw_endpoint interface directly to implement an endpoint object in a client.
2020-03-24 17:17:24 +02:00
'module-session-manager/endpoint.c',
extensions: implement new session manager extension This extension, implemented in module-session-manager, implements a set of objects that are useful for session managers.
2019-05-23 18:59:05 +03:00
'module-session-manager/protocol-native.c',
session-manager: implement export functions for session-manager objects
2020-03-24 13:14:18 +02:00
'module-session-manager/proxy-session-manager.c',
session-manager: implement factories for session, endpoint-stream & endpoint-link Heavily based on the endpoint factory
2020-03-26 14:02:56 +02:00
'module-session-manager/session.c',
extensions: implement new session manager extension This extension, implemented in module-session-manager, implements a set of objects that are useful for session managers.
2019-05-23 18:59:05 +03:00
],
c_args : pipewire_module_c_args,
include_directories : [configinc, spa_inc],
install : true,
install_dir : modules_install_dir,
meson: add rpath on the modules_install_dir for all modules Otherwise the dynamic loader won't be able to find libraries in modules_install_dir we link against fixes #214
2020-03-08 09:38:20 +01:00
install_rpath: modules_install_dir,
extensions: implement new session manager extension This extension, implemented in module-session-manager, implements a set of objects that are useful for session managers.
2019-05-23 18:59:05 +03:00
dependencies : [mathlib, dl_lib, pipewire_dep],
)
zeroconf: add avahi zerconf discover module Discovers remote sinks and sources and load the tunnel module to make a local sink and source for them.
2021-05-13 18:05:26 +02:00
if avahi_dep.found()
pipewire_module_zeroconf_discover = shared_library('pipewire-module-zeroconf-discover',
[ 'module-zeroconf-discover.c',
'module-zeroconf-discover/avahi-poll.c' ],
c_args : pipewire_module_c_args,
include_directories : [configinc, spa_inc],
install : true,
install_dir : modules_install_dir,
install_rpath: modules_install_dir,
dependencies : [mathlib, dl_lib, rt_lib, pipewire_dep, avahi_dep],
)
endif
Reference in a new issue Copy permalink