| Age | Commit message (Collapse) | Author |
|---|
|
Flathub requires this now.
This is done in the same way as the build number.
|
|
|
|
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 #4567
Fixes #4197
Fixes #3496
Fixes #3429
Fixes #3265
|
|
|
|
`overlay_gl/init_unix.c` is inherently Linux and FreeBSD specific, so
the build will fail until an OpenBSD implementation exists.
|
|
Encourage OS package maintainers to run tests by `packaging=ON` implying
`tests=ON`.
Keep `online-tests=OFF` by default since it is common practise for
packages to be built in unprivileged environments, e.g. without network.
|
|
|
|
Having a separate RELEASE_ID just unnecessarily complicates drafting
releases. Plus, now that we are using different build numbers for every
new build anyway, a separate release ID is really not necessary.
|
|
In theory LTO could give us a bit more performance than what we are
currently seeing. Client-side this will probably not be very noticeably
but on the server-side a few drops of extra performance can't hurt.
LTO will be enabled by default in all non-Debug builds. It remains
disabled for Debug builds as this is expected to be the kind of build
that a developer will use when they perform their work and there it is
useful to be able to go through multiple iterations of the program,
without waiting long times on the linker each time.
|
|
Using a four-segment version (major.minor.patch.build) is causing issues
on Windows, because it tends to ignore the fourth version number in most
cases. This can cause upgrades to fail and/or multiple entries being
created in the installed applications list.
For this reason, this commit changes the version format to be
major.minor.build.
Fixes #4921
|
|
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).
|
|
According to https://doc.qt.io/qt-5/macos.html#supported-versions Qt5
itself only supports macOS down to version 10.13. Given that our project
is completely Qt-based, it does not make sense to target a lower version
of macOS than that.
|
|
Now that the 1.4.x branch has been split off, the current master branch
must now be considered to be for version 1.5.0.
|
|
In the old qmake build system we included the functionality to bundle Qt
translations into our executable (potentially overwriting some of them).
See https://github.com/mumble-voip/mumble/blob/f5bf5f17f3c207bb18ecd2dfc9ccdfa3136b6c7f/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
|
|
|
|
This commit introduces a new plugin framework into the codebase of the
Mumble client. Note that "plugin" here really refers to a (more or less)
general purpose plugin and is therefore not to be confused with the
previously available positional data plugins (only responsible for
fetching positional data from a running game and passing that to
Mumble).
The plugin interface is written in C, removing the compiler-dependence
the old "plugins" had. Instead plugins can now be written in an
arbitrary language as long as that language is capable of being compiled
into a shared library and also being capable of being C-compatible.
As already indicated a plugin is essentially a shared library that
provides certain functions that allow Mumble to interface with it.
Inside Mumble the so-called PluginManager is responsible for managing
the plugins and relaying events to the respective callbacks. Plugins
themselves can also interact with Mumble on their own initiative by
using the provided API functions.
Fixes #2455
Fixes #2148
Fixes #1594
Fixes #2051
Fixes #3742
Fixes #4575
Fixes #4751
|
|
Apparently the first commit (59ae429972c16c377135bcccfee646b7df446933)
did not include all files.
Furthermore the used script tended to produce funny results in certain
cases. This has been fixed and as a result thereof a few more changes
were made in this second run.
|
|
By increasing the batch size, the benefits of the unity build are
expected to increase as well.
|
|
This is needed in order for the <cmath> header to also define constants
like M_PI. Instead of manually defining the macro every time before
including <cmath>, the macro is now defined via cmake and thus always
defined.
|
|
The copyright end year displayed in the About dialog was hardcoded to
2020. This commit replaces the hardcoded version with a dynamic version
that uses the year the software was actually built as the end date.
Fixes #4784
|
|
Mach_override, used for dynamic code replacement in overlay, does not
support arm (at all).
Until we have a different implementation, we disable it on ARM macs.
|
|
The build number can be specified through the new "BUILD_NUMBER" variable.
This change is very important on Windows, for two reasons:
- It allows to easily identify binaries simply by looking at their version.
More specifically, we can guess what build they're part of.
- Right now snapshots can not be updated without uninstalling first, because the version is the same (i.e. 1.4.0).
By increasing the 4th digit of the version for every build we can solve the issue.
This commit also takes care of renaming a few variables so that they're consistent and also clearer.
For example, "version" is now "RELEASE_ID".
|
|
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
|
|
We used EQUAL to compare the option's value to a String. This however does not work as according to
the cmake documentation on EQUAL says
"True if the given string or variable’s value is a valid number and equal to that on the right."
As we are not comparing numbers but "real Strings", we have to use STREQUAL instead.
|
|
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.
|
|
This was a leftover from the previous QMake options
but had no effect at all with CMake when enabled.
Distributions should use -DCMAKE_BUILD_TYPE='None'
to compile Mumble with the default compiler flags.
|
|
This satisfies the need to set the Release build type for generators that recognize it and simplifies the output for the build type in the cli.
|
|
|
|
The way the deprecation check for BUILD_TESTING worked, it would issue a
warning in any case from the second run onwards (as CTest will set this
variable to the cache)
|
|
Previously an empty String would be printed as the build type as the
Release-branch wasn't handled properly in the cmake file.
|
|
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.
|
|
Mumble usually ships with all its plugins in /usr/lib/mumble/* but the
new make install target installs them directly into /usr/lib/*.
This however can lead to certain files being overwritten.
Therefore these paths are changed in order to install these libraries
into /usr/lib/mumble/* again.
Fixes #4477
|
|
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.
|
|
Instead of having to change the version number and the build year in all
those files manually, we let cmake do the work by replacing the
respective values in templates.
|
|
|
|
In addition to Mumble's version and the target architecture, also print
the used build type.
|
|
Instead of checking for the variable CMAKE_CONFIGURATION_TYPES, we now
use the dedicated property GENERATOR_IS_MULTI_CONFIG in order to
determine whether the used generator is a multi-config generator and
therefore does not respect the CMAKE_BUILD_TYPE variable.
|
|
The previous output used x86 and 32bit as synonyms (as well as x64 and
64bit) which is incorrect.
|
|
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.
|
|
Instead of only printing the Mumble version that is being built, the
architecture that cmake is currently configuring for is displayed as
well.
In order to make this information more visible, they are surrounded by a
row of hashtags.
This change should make it more obvious to users if they happen to build
the wrong version/architecture (as can easily happen on Windows).
|
|
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.
|
|
|
|
|
|
|
|
|
