Patch supplied by Helmut Grohne <helmut@subdivi.de> in Debian bug #919453https://bugs.debian.org/919453
Use set variable PKG_CONIFG to allow calling the pkg-config for the
architecture supplied in the build environment to allow cross building.
We used to use DIST for referencing extra files that should be included
in our tarballs created by 'make dist'.
However, we've since migrated away relying on 'make dist' in release.pl.
Instead, we include everything, and have a list of items to exclude, such
as IETF RFC drafts distributed in 3rdparty/speex-src that do not adhere to
the Debian Free Software Guidelines.
This commits adds a 'make check' target to Mumble's build.
To enable tests, add CONFIG+=tests when configuring the
Mumble build.
It's all based on Qt's existing support for this.
To add a testcase, simply add CONFIG+=testcase to its .pro file.
Then, that test will automatically be built and run when 'make check'
is run.
This commit also adds the recent TestCryptographicHash test to the
test suite, as the -- for now -- only test.
The option currently works only on Linux, since there was no need in Windows, until now.
During a MinGW build test we noticed that minhook can be compiled only with MSVC, for various macros and probably other things.
This adds a dependency on a small library, XInputCheck, which is
a function abstracted away from SDL. All it does is check whether
a given DirectInput guidProduct is an XInput device.
The protobuf code creates lots of spurious warnings
throughout our compile which we can do nothing about.
This patch changes the way we integrate the generated
code in our build to work around this.
We now run protoc and generated code compilation as a seperate
mumble_proto target producing a static lib. This lib is then
linked by mumble and murmur.
The folder of this module is added to the include paths so
Mumble.pb.h is available. On Unix platforms a -isystem entry
is added for the directory.
The advantages of this approach is that we can disable warnings
for the compilation of this target like we do for 3rd party modules.
Additionally we no longer generate and compile the protobuf files
twice.
The speex library has been split into a codec part
(speex) and a dsp part (speex-dsp). As we still need
the codec for compatibility with 3rd party clients
only sending speex but still want the updates that
went into the dsp and codec since then this patch
modifies our build to enable that. To achieve that
we combined the two libraries back together. Doing
it this way might brittle but is only a temporary
solution until we can actually drop the codec part.
This splits fx11 into an x86 variant and an x64 variant.
This creates effects11_x86.lib and effects11_x64.lib, instead
of the single effects11.lib we had previously.
The minhook build is also tweaked. However, since minhook
is only used on x86_64, it is only built for x86_64.
Consequently, the library is still called minhook.lib.
The overlay itself is split into mumble_ol.dll and mumble_ol.exe
for x86, and mumble_ol_x64.dll and mumble_ol_x64.exe for x86_64.
This commit removes macx/overlay and merges
the OS X overlay into the Unix overlay in
overlay_gl.
Most of the overlay logic is exactly the same,
with most of the differences being in the
initialization code and the addition of few new
messages for the interactive client-in-overlay
feature that the OS X overlay suports.
The initialization code is factored out into
init_unix.c for Unix-likes and init_mac.c
for OS X.
These init files are #included by overlay.c.
That is, they're not separate translation
units. Doing it this way cuts down on the
total LOC count and overall complexity of the
code.
The interactive overlay support is ported
directly from the OS X overlay. It's mostly
a matter of supporting a few new message types:
OVERLAY_MSGTYPE_PID and OVERLAY_MSGTYPE_INTERACTIVE.
The overlay_gl.pro file in this commit is mostly
just a combination of the .pro files of the two
overlays, with a minor difference in the CFLAGS
for the OS X overlay. In old OS X overlay, the
overlay had an ".m" file extension, signalling
that it is an Objective-C source file to the
C compiler. Since the combined overlay has a
".c" extension, "-x objective-c" is added to
CFLAGS on OS X to tell the compiler to compile
the overlay as Objective-C code.
Prior versions of mach_override were small (a single file),
and we just had its source live in the OS X overlay directory.
Newer versions of mach_override use libudis86, so the file count
goes up a fair bit. So much so that it doesn't make sense to
have it live inside the OS X overlay anymore.
Because of that, this commit moves it into 3rdparty.
This changes Mumble on Windows to run a helper process,
mumble_ol.exe, instead of loading mumble_ol.dll itself.
Prior to this change, Mumble would load mumble_ol.dll and
call PrepareD3D9() and PrepareDXGI() to set up the overlay.
Then, if the overlay was enabled, it would call InstallHooks()
to enable automatic injection of the overlay into new processes.
Similarly, it would call RemoveHooks() to disable automatic
overlay injection when the overlay was disabled in Mmuble.
With this change, Mumble instead runs a helper process called
mumble_ol.exe. This process sets up the overlay (equivalent
to calling PrepareD3D9(), PrepareDXGI() and calling InstallHooks()).
While running, it'll automatically inject the overlay into new
processes, just like Mumble itself did previously. On normal exit,
the helper process calls RemoveHooks() to ensure automatic overlay
injection is disabled.
To enable the overlay, Mumble starts the helper process.
To disable the overlay, Mumble terminates the helper process.
If the helper process dies when it is supposed to be running,
Mumble restarts it to ensure that overlay injection keeps
working as intended.
This change is the first part of enabling both an x86 and an x64
overlay to be active in Mumble at the same time. Since we cannot
load a 32-bit DLL into a 64-bit process (or vice versa), we need
a helper process for each architecture to reach our goal.
Note however that this commit in itself does not make it possible
for Mumble to run both an x86 and an x64 overlay at the same time.
This will come later.
This commit adds MinHook as a 3rd party
dependency and adds an alternative HardHook
implementation that makes use of MinHook.
This new MinHook-based HardHook implementation
allows us to provide an overlay for Mumble on
Windows x64.
The x64 overlay hasn't seen much testing in
real-world x64 games, except some minor testing
for World of Warcraft running in x64 mode, where
it works just fine.
There seems to be a compatibility with the Uplay
overlay, which causes Far Cry 4 to crash at the
"Press any key to continue" screen that is shown
just after launching the game. However,
Assassin's Creed: Unity works fine, so it might
just be a Far Cry 4 issue.
The x64 overlay also seems to interoperate with
the Steam overlay just fine.
I think this is a good starting point for the
feature. Let us get it into snapshots and let
us try to squash any addition bugs we find.
The g15helper program is currently coded against Logitech's
legacy G15 SDK. Logitech's newer SDK, which is the only one
shipped in their newer versions of Logitech Gaming Software,
is not compatible.
For OS X, the legacy SDK is still available for download
if you download the version of LGS (GamePanel 3.x) that
supports OS X 10.4 through 10.6. However, the SDK shipped
in this version of their software uses slightly different
paths than we expect.
This commit changes the paths to make sense with the SDK
shipped with the GamePanel 3.x software.
With this change, CONFIG(static) on Windows will cause the Mumble client's
application logic to be built into a .DLL called mumble_app.dll
(based on pcgod's previous DLL changeset).
Since src/mumble will now be built as a DLL, a wrapper executable is available
in src/mumble_exe. This wrapper is currently implemented such that it will
load mumble_app.dll from the directory that it resides in.
This means that when building statically, src/mumble and src/mumble_exe will
now give us the following products:
src/mumble: mumble_app.dll
src/mumble_exe: mumble.exe
Along with the two major points above, this change also adds a Python script
to the build, 'gen-mumble_app-qt-def.py', whose job is to construct a module
definition (.def) file for mumble_app.dll. The generated module definition
lists the Qt symbols that are needed for the manual positioning plugin to work.
If we need to expose more symbols in the future (say we want to implement
more plugin kinds than the current positional audio plugins), we now have
the infrastructure in place to do that.
