Signed-off-by: falkTX <falktx@falktx.com>

* Move jack_control to dbus dir

dbus/jack_control:
The `jack_control` script is dbus specific and not part of the original
jack tools. As the files offered by jack-example-tools are now
optionally not built, the script needs to be made available from a
location, that is not ignored when omitting the build of
jack-example-tools files.

* Move installation of jack_control to dbus integration

dbus/wscript:
Install `jack_control` script if building/installing jackdbus.

tools/wscript:
Remove (unconditional) installation of `jack_control` script.

* Alternative attempt at fixing CI

Signed-off-by: falkTX <falktx@falktx.com>

* Cleanup

Signed-off-by: falkTX <falktx@falktx.com>

* Forgot apt-get update

Signed-off-by: falkTX <falktx@falktx.com>

wscript:
In 61a708f2c6 a regression has been
introduced, that always leads to not building the jack-example-tools
(even if selected).
This has been introduced due to the use of the wrong configuration
environment `HAVE_JACK_EXAMPLE_TOOLS`, whereas it should have been
`BUILD_JACK_EXAMPLE_TOOLS`.

.{ci/*,travis.yml}:
Remove unused travis-ci integration.

svnversion_regenerate.sh:
Remove unused script.

dbus/jackdbus.c:
Rely on the `JACK_VERSION` define instead of `SVN_VERSION` (included
from svnversion.h).

dbus/wscript:
Add the `JACK_VERSION` define based on `JACK_VERSION` configuration.

wscript:
Remove all code related to the use of `svnversion.h` and
`svnversion_regenerate.sh`.

ChangeLog.rst:
Add changelog entry for new configure option to allow not to build
files provided by jack-example-tools.

wscript:
Add option `--example-tools` to allow optional build of executables and
libraries provided by jack-example-tools (defaults to True).
It can be used as `--example-tools=yes|no` or `--no-example-tools` or
plain `--example-tools`.
Based on the new option, set the configuration environment variable
`HAVE_JACK_EXAMPLE_TOOLS` which is used throughout the configuration
and build steps to include the `example-clients`, `tools` and `tests`
subdirectories.

man/wscript:
Provide the `HAVE_JACK_EXAMPLE_TOOLS` build environment variable to the
`fill_template` script as second argument.
Remove unused imports.

man/fill_template:
Change the behavior of the script to only create all man pages if the
second argument to the script is `True` (the jack-example-tools are
being built), else only create the man page for jackd.

jack.pc.in:
Add the custom `jack_implementation=jack2` pkgconfig variable to the
generated jack.pc file to be able to distinguish jack implementations.
As jack implementations exist with jack1, jack2 and pipewire-jack, it is
not (easily) possible to distinguish them by looking at the version
alone (particularly the case with jack2 vs. pipewire-jack, as they share
the same headers).

This is a no-op since the line was already commented out, to make it
compile on FreeBSD. But it deserves an explanation:

The _POSIX_C_SOURCE macro is meant to restrict the C library to a
certain POSIX standard, not to enable features. This is inappropriate
here because:

1. Jack already uses non-POSIX functions. E.g. JackPosixSemaphore.cpp
   references gettimeofday(), which is part of the X/Open specs.

2. C++ does not define a POSIX level to be based on. Headers from the
   C++ standard library may (and do) break when the POSIX feature level
   is restricted.

The canonical way is to only set the feature level through the
"--std=gnu++11" compile options.

Features:
 * Internal workings more in line with other Jack drivers.
 * Use poll() for wait and sync instead of blocking I/O.
 * Allows to use Jack in "async" mode.
 * Calculate DSP usage correctly.
 * OSS buffer management to achieve stable latencies.
 * Latency correction for asymmetric OSS buffer use.
 * More robust handling of over- and underruns.
 * Handle format changes forced by the OSS interface.
 * FreeBSD 24bit samples are always packed.

No changes to the driver parameters or the user interface.

Start with an unchanged copy of the Solaris OSS driver.

This is forbidden (returns EINVAL)

* macOS: Pass JackMachSemaphore send right via mach_msg IPC

Previously, JackMachSemaphore would communicate the send right for the
semaphore object from the server to a client via a named service
registered via `bootstrap_register`. However, to do this, it would
register the semaphore's port as the service port directly.

In theory this ought to be fine, however in practice, macOS `launchd`,
which provides the `bootstrap_register` interface, does not correctly
detect when such a port becomes dead, and incorrectly believes that the
service that it provides is forever alive, even past the end of the
`jackd` process' (and therefore the semaphore's) existence. This seems
to be *specific* to semaphore ports, as `launchd` is expecting a
standard IPC port, owned by the task, not the kernel. This prevents
`jackd` from later registering another service with the same name, as
`launchd` rejects the registration as conflicting with an active service.

To get around this, `jackd` previously added a counter to the end of the
named service registrations, allowing old services to remain in the
system until the end of the session. To prevent things getting out of
hand, this was capped at 98 service registrations for a given semaphore
name. This led to #784, in which running a client for the 99th time
resulted in the semaphore creation failing and the client failing to
connect.

As `launchd` outlives multiple runs of `jackd`, this situation persisted
across restarts of `jackd`, requiring a restart of the user's session
(i.e. a reboot) to fix.

An initial attempt at fixing this (see #785) tried passing the port
rights directly via shared memory, however mach is too clever for us and
foils that plan by having port names be looked up in a per-task table
(sensible when you think about it).

In this commit, we use mach IPC messages to transfer the send right for
the semaphore from the server to the client. By registering a standard
IPC port with the bootstrap server, the service registrations are
correctly torn down when the ports are destroyed.

It works something like this:

* Server creates IPC port and registers it globally via `bootstrap_register`
* Server listens on IPC port for messages
* Client looks up IPC port via `bootstrap_look_up`
* Client sends it a message
* Server replies with a message containing a send right to the
semaphore's port
* Client is then free to use the semaphore port as before.

This resolves #784.

* Improve error handling

* Add myself to Authors

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

This reverts commit 9a33cc254c.

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

Signed-off-by: falkTX <falktx@falktx.com>

It uses c++ sources and runtime therefore its best to use c++ compiler
to build it so it can find the correct runtime, cross compiling with
clang fails

x86_64-yoe-linux-ld: example-clients/simdtests.cpp.28.o: undefined reference to symbol '__cxa_call_unexpected@@CXXABI_1.3'

Signed-off-by: Khem Raj <raj.khem@gmail.com>

Signed-off-by: falkTX <falktx@falktx.com>