Previously, they would only be added by accident via PKGCONFIG.
Moving the Protobuf-related things into mumble_proto revealed this,
as it broke the build for Unix-like systems.
This commit should let mumble_proto find protobuf in the build env,
and unbreak the build.
The default Boost installation paradigm for non-Unix boxes
is to install Boost into your include directory with a version
attached. For example:
include/boost-1_49/boost
However, it is also possible to install Boost in a more traditional
manner, such that it simply lives in include/boost, instead of having
a version attached -- this is called a tagged installation, and
is triggered via 'b2 --layout=tagged'.
All of our build environments use tagged Boost installations, and thus
we can avoid the embedded versions now that we have transitioned to
using build environments from mumble-releng.
While we don't necessarily want to force the build environments
from mumble-releng on people, the versioned includes are a bad idea
in the first place, because they require constant maintenance.
Nothing prevents people from adding a non-tagged include themselves,
if that is what their home-grown build environment uses.
We do not plan on using ICC to build mumble now or in the
foreseeable future. Hence this patch drops it.
It also removes some backwards compatibility code that
worked around bad C compatibility with VC10 mostly
related to math header usage.
Updated compiler.pri to make use of the new /Zo
option to improve our debugging capabilities on optimized
builds. This flag is officially supported since
Visual Studio 2013 Update 3.
This patch updates the compiler flags under the assumption
of us using VC12. This mostly consists of dropping flags
this compiler already set by default as well as removing
a conditional. This might even still build from this point
on VC10 support is considered to be dropped.
These CONFIG options allow a .pro file to select which toolchain
its target should be built with.
To force a target to always be built for x86 (in both x86 and
x86_64 build environments), set CONFIG+=force-x86-toolchain.
The same thing is possible with force-x86_64-toolchain.
In Xcode 5, the xcrun tool includes a --show-sdk-path parameter
which, as the name implies, can be used to query the system for
a usable OS X SDK path. However, xcrun in Xcode 4 does *not*
include this parameter.
We used this parameter unconditionally, which lead to failures
when using building against Qt 4 when using Xcode 4.
This change modifies the SDK selection code to first attempt to
query for the OS X sdk using the --show-sdk-path parameter. If
that fails, we try to fall back to using a 10.8 SDK living in
a DEVELOPER_DIR found via xcode-select --print-path. If that
doesn't exist either, we warn the user and abort the build.
This should allow people to build Mumble on most systems without
having to resort to manual .pro file editing.
For Qt 5, we simply use 'macosx'. For Qt 4, we query via 'xcrun',
just like Qt 5 does under the covers.
This allows us to avoid changing the hard-coded OS X SDK every time
a new SDK is released. As long as Xcode is up-to-date, we'll build
with the new SDK automatically.
This allows Mumble to build with Boost that has been
configured with the --layout=tagged or --layout=system
options.
The win32-static build environment uses this kind of
Boost install.
This means we'll be able to keep Boost up-to-date without
modifying compiler.pri each time.
* Implementation relied on local static variable initialization being
threadsafe which is not the case before C++11.
* To retain lazy initialization now using boost::call_one() to force
thread-safe first get()
* This adds a non header dependency to boost::threads for the windows
build.
