This is a workaround for a bug that appeared in a recent version of CMake.
WORKING_DIRECTORY prepends the specified path to a list instead of using it directly, resulting in:
cd /D D:\a\1\b\overlay\overlay_xcompile-prefix;D:\a\1\b\overlay\overlay_xcompile-prefix\src\overlay_xcompile-build
For reference, this causes the build to fail on Windows with the following error:
"The filename, directory name, or volume label syntax is incorrect."
This commit simply removes the parameter from the ExternalProject_Add() call, since the default working directory is perfectly fine.
Using a separate module instead of encoding the different flags for
different compilers into our own cmake source code should clean things
up a bit and make the intention more clear (as the flags sometimes have
rather cryptic names).
This commit also contains a functional change in that it removes the
"fast-math" compile option (from optimized builds) as this is
incompatible with at least Opus.
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
Apparently the first commit (59ae429972)
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.
This commit explicitly excludes certain targets from being built in a
unity build (or rather they continue to get built normally) as they
cause compilation errors in these kind of builds.
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".
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.
If the library is not explicitly specified, the compiler will choose a
version automatically. This chosen version however can easily conflict
with the one we set for the overlay-executables which would then cause a
conflict to arise (2 different versions of the library referenced) about
which MSVC will then warn us:
defaultlib 'MSVCRT' conflicts with use of other libs;
use /NODEFAULTLIB:library
Ref: https://stackoverflow.com/q/3007312/3907364
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.
This commit removes all qmake-related build-files from the system. We
have now migrated to cmake and are no longer maintaining qmake anyways
and therefore there is no reason to keep it.
Removing it also clearly states to any potential user/programmer that
this project is no longer intended to be compiled with qmake.
Given that the .pri files no longer exist, the mumble-version.py script
had to be adapted to read the version from the CMakeLists.txt file
instead.
Furthermore a few of the submodules support cmake natively and therefore
we no longer need the src/buid-directory approach in order to build
them. The respective build dirs have been removed and the src-dirs have
been renamed.
We are working on adding a 32 bit Windows build to Azure Pipelines and noticed that it was failing due to "IUnknown" not being defined.
The issue was quickly fixed by including <unknwn.h>, however we wondered why we didn't encounter it with the 64 bit Windows build (which compiles the overlay library as 64 bit and 32 bit).
Turns out minhook was used for the 32 bit overlay library due to the if() logic missing a crucial condition: "BUILD_OVERLAY_XCOMPILE" must be false, because "64_BIT" is true due to it being defined outside of the cross-compile environment.
CMake prioritizes MinGW over MSVC, which means that the first is used if found in PATH.
Since overlay-xcompile is only meant to be used with MSVC (MinGW provides "-m32" to build as 32 bit), this commit forces the use of "cl".
GCC and Clang provide the "-m32" and "-m64" options, which tell the compiler to build as 32 bit and 64 bit, respectively.
Unfortunately MSVC doesn't provide similar options, thus this commit converts "overlay" from a subdirectory to a project.
If the build is 32 bit, the project is processed a single time and compiles a 32 bit library.
If the build is 64 bit, the project is processed two times and compiles a 64 bit and a 32 bit library.
1.3.0 has been released. master now represents the current state of
development towards the next feature release 1.4.0.
Bugfixes for 1.3 will happen in the 1.3.x branch.
Compared to earlier version bumps we bump a lot more files because of
we produce more artifacts; overlay process, dll and exe split, etc.
This should have happened right after the 1.3.x branch was split off.
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.
Use correct types for handling pointer size/memory addresses.
Make use of boost optional as GetFnOffsetInModules return type. The
unsigned return type does not allow for negative error values anymore,
which we did not make use of anyway, and optional is more explicit.
Replaces workaround/error detection from the commits
114495e59fa3e7958f16Fixes#1924
It is better to be explicit and API correct, even if the resulting
types ended up to be the same through typedefs or the implementation
reinterpret-casting to a memory address pointer.
As provided by Remadan in mumble-voip/mumble#3029.
LaunchPad is Daybreak Games's own launcher, used for games such as
PlanetSide 2 (Standalone) and others.
This was originally implemented in
2f07778a0e.
This change was a mistake. We use the WH_CBT hook to inject our DLL into
potential targets. That means that every mouse/keyboard event will trigger
an attempt to load our overlay DLL, if it isn't already loaded.
That, combined with the new ability for the overlay to decline being
injected caused problems for processes that are blacklisted by Mumble:
Every mouse/keyboard event would attempt to load the DLL, go through the
exclusion checks (query the process tree, query the registry, find out
that the process is blacklisted, unload the DLL...).
We can't have that, so let's just revert this.
