Crashpad handler was initialized quite late since we were waiting for settings. However the settings in crashpad are persistent itself, hence we can start it at the earliest possible time and change the upload settings independently later. The only prerequisite is to have QCoreApplication constructed in order for the application name to be available.
ref T652
The config is loaded from json files by qmake, and we define the qmake
function `swiftConfig` for checking whether a feature is enabled.
This function can be directly used in `buildconfig_gen.cpp.in`,
so the trick with C++ comment tokens in variables is not needed.
Summary:
Only blackcore includes the headers of crashpad. It is therefore
not necessary to add this include paths globally for all projects.
Reviewers: #swift_pilot_client, kbasan
Reviewed By: #swift_pilot_client, kbasan
Subscribers: jenkins
Differential Revision: https://dev.swift-project.org/D70
Crash handler launches an external crash handler executable called
swift_crashpad_handler. It monitores the parent process and produces
a local dump in case of a crash.
For release builds, the dump is also uploaded to a crash report server.
refs #490
CBuildConfig including private keys etc. should not be part of a
public library API. Therefore link it into a static library, which
is not available to end users.
refs #645
* Warning flags for elevated warnings as discussed: no /W3, explicit /wd
* fixed include in hotkey samples
* removed outdated QMAKE_CXXFLAGS += -std=c++0x
- SimConnect handling done in CSimulatorFSX
- Exception handling done by CSimConnectException
- Data definitions done by CSimConnectDataDefinition
refs #142
* Added further DBus tests
* Crossover from refs #85 , removed dependency from generator adaptor and XML files, as this will not work anymore in the future
* Removed from .pro DBUS_ADAPTORS , DBUS_INTERFACES, QDBUSXML2CPP_INTERFACE_HEADER_FLAGS , QDBUSXML2CPP_ADAPTOR_HEADER_FLAGS
* Added interface, as this will be no longer generated
* Removed samples no longer required, the sample no represents a framework to test DBus marshalling / unmarshalling
use the device information of this context. Sound shall be played on the
same computer as the voice.
* Adjusted .pro file
* Methods for SELCAL in context
* New XML file (DBus)
* changed the place where I can obtain the current in/output device
* rename CStatusMessages to CStatusMessageList
* rename NetworkVatlib to CNetworkVatlib
* replace all occurrences of Realname with RealName (correct camel case)
* CSequence method corresponding to CList::append is push_back
* don't compile the qdbuscpp2xml metadata plugin by default
* CAircraftIcao string members always trimmed and capitalized
* added CComSystem::roundTo25KHz
* using epsilon comparison in a couple of places
refs #81
