If the systemd module was not installed (or could not be located by
pkg-config for other reasons), a big chunk of text would be emitted to
stdout stating that no such module could be found and how one might
resolve this issue. However, we don't want to throw this at our users as
we have backup code paths implemented for the case in which pkg-config
can't query the necessary information.
This commit makes sure that these warnings are not emitted anymore.
Previously we would define our install paths as relative paths when
using the packaging option and turning them into absolute paths
otherwise.
While relative paths are required for CPack to work properly, we use
the paths e.g. for passing them in via macros and there we absolutely
require the full, absolute paths to be passed.
Thus, this commit removed the discrepancy of the results when built with
packagin=ON vs packagin=OFF and now always defines the install paths as
relative paths. However, we now keep an additional set of paths around
that are now always absolute.
Fix a typo in the COMPILER_HAS_MBIG_OBJ test which fixes this failure:
c++: warning: Wa,-mbig-obj: linker input file unused because linking not done
c++: error: Wa,-mbig-obj: linker input file not found: No such file or directory
The gRPC implementation never left the experimental state and never
reached a properly stable state to the point where we would feel good
about enabling it by default. In addition to that, there has been no
further attempts at finding and fixing the encountered issues in the
implementation (except #3947 but that was discontinued).
As such we had an essentially unmaintained piece of code in our server
implementation that was known to be buggy and that nobody wanted to fix.
In addition to that the implementation itself could not be considered
very clean or elegant and therefore only represented a few smelly
corners in our code base.
For this reason, we decided to remove the gRPC support entirely from
Mumble (for now).
What we hope to gain by that is:
- Prevent people from building unstable server versions and then coming
to us complaining that it crashed/misbehaved
- Removing (essentially) dead code
- Reduce the RPC implementation complexity
That last piece is crucial: By removing gRPC support we reduce the
amount of supported RPC frameworks to only one (ignoring DBus for now).
Our future plans include a refactoring of how RPC is being handled and
implemented and only having to worry about maintaining compatibility
with one RPC system is much easier than having to worry about two (with
(slightly) different APIs).
Once the RPC implementation has been rewritten, more RPC backends may be
reintroduced and in that process we might investigate adding a proper
gRPC implementation to the code (that then hopefully is more stable than
the current one).
Fixes#4567Fixes#4197Fixes#3496Fixes#3429Fixes#3265
Found via `codespell -q 3 -S *.ts,./3rdparty,./3rdPartyLicenses -L
aci,ba,crypted,datas,doubleclick,feld,hsi,ist,keypair,ro,unknwn`
Includes misc. fixes to .github/ and cmake files
Previously the plugin installer attempted to select the correct plugin
binary by its file extension but it turns out that this is not a unique
choice (e.g. .so is supported on macOS and on Linux).
Therefore this commit introduces a mandatory manifest file that is to be
present in plugin bundles that contains the mapping for which binary to
use on which OS and for which architecture.
Because a plugin bundle now has to follow such a strict format, it is
now also mandatory for the bundle to have the file extension
.mumble_plugin (previously .zip was allowed as well).
These macros are defined in Windows.h if the NOMINMAX macro is not set.
This then causes all other uses of the terms "min" and "max" (as e.g. in
std::min, std::numeric_limits<>::min, etc.) to fail, which is
unacceptable. Therefore NOMINMAX is now defined globally when compiling
on Windows.
In the old qmake build system we included the functionality to bundle Qt
translations into our executable (potentially overwriting some of them).
See f5bf5f17f3/src/mumble/mumble.pro (L692-L728)
This functionality was not ported over to cmake which could lead to Qt
standard texts (e.g. "Ok") not being translated.
This commit ports the old functionality to the new cmake build system.
Note however that this new functionality is only enabled by default, if
a static build of Mumble is created. In other instances the option can
be specified manually.
Fixes#4359
Previously we re-generated our translation files when building, causing
them to change in the source tree.
With this new approach, we assume that the .ts files are already
up-to-date and thus we only compile them to .qm files that are stored in
the build directory. That way the source dir remains uncluttered.
We used this function to set multiple properties at once which is not
supported. Instead what happens is that the first referenced property is
populated with a list of values (the following words in the set_property
function).
Thus the set_property call had to be separated into two individual calls
each setting only a single property to the desired value.
If the *_plugin_import.cpp files already exist before the latest cmake
changes for unity builds are pulled, the necessary property does not get
set on these files, which can cause build failure.
The *_plugin_import files will cause collisions in a unity build, so we
have to make sure that they are built separately as usual.
Furthermore the ObjecticeC files don't play well in unity builds (it
seems like they are then treated as cpp files). Thus they are excluded
from that as well.
WinGUID.cpp must also not be included as that breaks the DEFINE_GUID
macro wizardry needed to avoid redefinition errors.
Using a unity build tends to create large source files. With that it is
easily possible to hit the object file's size limit resulting in the
"C1128: number of sections exceeded object file format limit" (MSVC) or
"File too big" (GCC) error.
In order to avoid this, this commit sets the necessary flag to extend
that limit.
This PR updates the copyright notices of all files. For doing so
it introduces a script that can do this automatically.
Furthermore a few files that are no longer needed got removed.
If a package is searched for with multiple casings (as is currently the
case for libsndfile), it will be very hard to use the resulting cmake variables
(e.g. <name>_FOUND, <name>_LIBRARIES) as one does not know which casing was
eventually found.
This issue actually broke the build on macOS when installing libsndfile
via homebrew.
This change sets the all-lowercase version of the package
name variables (if multiple cases of the spelling are contained in the
package's aliases) so that this can then be used further down to reference
the result, without needing to iterate through all the options again to
determine which case was found.
Fixes#4790
Remove CPack and previous WiX installer projects and sources
Add toolset and for WixSharp to facilitate client and server builds
individually or collectively.
Add multilanguage build with packaging=ON and translations=ON, and
standard build with packaging=ON. Builds are also aware of client and
server option settings.
Add correct LICENSE to installer
Libraries should only be installed if they are built as shared
libraries. Static libraries should only be needed during Mumble's
compilation and are therefore no required dependencies that have to be
installed alongside Mumble.
We need to use relative install paths if we intend to invoke CPack (it
errors on absolute paths) but for everything else we should prefer
absolute paths. This is needed as the dynamic libraries that are being
loaded by Mumble have to be loaded by an absolute file path (and the
macro containing that path is set to the install path's value).
Installation paths can now be fine-tuned by setting the respective
MUMBLE_INSTALLATION_* variables when invoking cmake.
Additionally some components that only had install rules for a certain
OS are now installed on all OSes as these components should be needed
there as well.
Installation paths can now be fine-tuned by setting the respective
MUMBLE_INSTALLATION_* variables when invoking cmake.
Additionally some components that only had install rules for a certain
OS are now installed on all OSes as these components should be needed
there as well.
We are using a custom FindGRPC.cmake script in order to locate the gRPC
targets as not all distribution variants of gRPC include the respective
cmake support. Those that do however will use "gRPC" (note the lowercase
"g") as the target's name and therefore our current way of searching for
it via find_pkg won't find them.
The solution is to first look for "gRPC" and only if that fails, check
for "GRPC". This way the official target "gRPC" should be found and
preferred if present.
Fixes#4508
Co-Authored-By: Thomas Lange <thomas-lange2@gmx.de>
The changed files used a generator expression in an if-statement, which
is invalid as these generator expressions are not evaluated during the
initial configuration stage (at which point the if-statement is
evaluated).
This commit changes the use of the generator-expression in such a way
that it will actually do what it was meant to.
Note that this commit also enables position independent code for all
platforms and all build-types instead of only for debug builds on unix
systems. This was the preferred choice instead of porting the -fPIE
compiler option to use proper generator expressions as the presence of
these options caused linking errors with Celt/Opus.
We used the BUILD_TESTING variable in order to indicate whether or not
tests shall be built. However this variable is used by e.g. CTest
already and there it had a different default value. Therefore we now
deprecate BUILD_TESTING and use the tests option instead.
This also fits better with our other options in terms of casing.
If the user uses -Ddebug-dependency-search=OFF, then the find_pkg
function will not perform its searches using the QUIET flag causing a
lot of (valuable) information to be printed to the screen.
This commit fixes two issues:
1. The installer ignoring Mumble < 1.4.0 installations. This resulted in two separate entries in the installed programs list and a cluttered installation folder.
2. The installer thinking that the product is already installed even if it's a different build.
The first problem was caused by CMAKE_WIX_UPGRADE_GUID being explicitely set to a wrong value, due to an extra line in the file.
The second problem was caused by CMAKE_WIX_PRODUCT_GUID being explicitely set to a static value due to us misunderstanding the "ProjectGuid" variable in the WiX project we used until 1.4.0.
We thought it referred to the MSI product GUID, but instead it's just the MSBuild project identifier.
Also, CMake's WiX documentation clearly says that the installer will abort if it detects a pre-existing installation that uses the same GUID: https://cmake.org/cmake/help/latest/cpack_gen/wix.html#variable:CPACK_WIX_PRODUCT_GUID
Without this change it could happen that get_targets returned
non-compilable targets (e.g. install or uninstall targets) and this
could lead to errors when e.g. trying to set compile options on those
targets.
In order to not be spammed with warnings from 3rdparty projects that we
make use of in Mumble, this commit modifies the respective cmake files
in a way that disables warnings for the respective projects.
