SteamFrame/OpenVR-AdvancedSettings-frame

Files

T

ykeara b883d2cffd default audio profile and view added

Update logging dependency from 9.84 to 9.89

This is the newest version that doesn't lead to compile errors. It has
also reduced the amount of "-Wexpansion-to-defined" errors on clang-msvc
by about 80 (from ~400 to 320).

Update easylogging license file

Originally came as LICENCE.txt (notice C instead of S in LICENSE),
renamed to better fit into the git history.

Move logging defines to QMAKE instead of logging.h

Defines done outside of easylogging++.h does not work according to
official documentation
(https://github.com/zuhd-org/easyloggingpp/blob/master/README.md#configuration-macros)

"NOTE: All the macros can be defined in one of the following ways:

1. Define macros using -D option of compiler, for example in case of
g++ you will do g++ source.cpp ... -DELPP_SYSLOG -DELPP_THREAD_SAFE
... (recommended way)

2. Define macros inside "easylogging++.h" (defining macros in other
files won't work)"

Linking to this issue:
https://github.com/zuhd-org/easyloggingpp/issues/590#issuecomment-346753951

We are using the developer recommended way of defining them by command
line.

What is assumed to be the intention of enabling debug logs before
including easylogging++ never actually did anything, hence this define
is dropped. Newer versions of easylogging++ uses the macro
ELPP_DISABLE_DEBUG_LOGS to _disable_ debug logs. Leaving that macro
undefined satisfies the original intent.

Move easylogging++ include into necessary files

logging.h previously had logic to enable debug logging even on release
builds. This logic was moved to the QMAKE file, hence the logging.h file
is no longer necessary.

Update easylogging++ to 9.96.7, turn on /WX for clang-msvc

Updating from easylogging++ 9.89 to 9.96.7 turns it from a header only
library to one requiring a source file. It has been added to sources
near the other third party includes in the QMAKE to signify that it
isn't a first party file.

Updating easylogging++ also means that clang-msvc can compile without
any warnings, hence turning on warnings as errors for that compiler as
well, to avoid any regressions.

updated to current

fixed formatting

fixed ptt add bug/compilerwarnings/c++14 target

cleaned up .pro file

fixed casting back to c++ style

added default profile and ptt profile view

fixed c++ casts

fixed logic error on getDevice functions

2019-01-03 15:37:20 -06:00

5.4 KiB

Raw Blame History

Building for Windows

Requirements

Locations and Environment Variables

Building

Contributing

Using with QtCreator

Using with Visual Studio

Requirements

For compiling:

Microsoft Visual Studio (tested on 2017 Community)
Qt Framework version later than 5.6 (tested on 5.10 and 5.11)

For pushing changes to the repo:

Python 3 (must be in PATH environment variable)
Clang format. Part of the LLVM collection.

Additionally, for fully building portable and installer release versions:

Locations and Environment Variables

The following environmental variables are relevant for building the project.

Environment Variable	Purpose
`QT_LOC`	Path to your Qt `\bin\` folder.
`VS_LOC`	Path to your Visual Studio `vcvarsall.bat` file.
`JOM_LOC`	Path to an `.exe` of `jom.exe`. Usually installed with Qt. `jom` is a wrapper around `nmake` allowing more threads to be used. It is not required, but using `nmake`is slower. If `JOM_LOC` isn't defined, or the `.exe` can't be found `nmake` will be used by default. To force using `nmake`, set `JOM_LOC` to a non-valid path like `1`.
`ZIP_LOC`	Path to your 7zip `.exe`. Both portable and installer will work.
`NSIS_LOC`	Path to your installation of NSIS containing the `makensis` file. Both portable and installer will work.
`CLANG_FORMAT_LOC`	Path to your `clang-format.exe`. Not necessary for building, but necessary for pushing changes to the repo.

If an environment variable isn't set a default value will be provided. The default values are shown in the table below.

Environment Variable	Default Value
`QT_LOC`	`"C:\Qt\5.11.1\msvc2017_64\bin\"`
`VS_LOC`	`"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat"`
`JOM_LOC`	`"C:\Qt\Tools\QtCreator\bin\jom.exe"`
`ZIP_LOC`	`"C:\Program Files\7-Zip\7z.exe"`
`NSIS_LOC`	`"C:\Program Files (x86)\NSIS\"`
`CLANG_FORMAT_LOC`	`"C:\Program Files\LLVM\bin\clang-format.exe"`

Additionally, these optional environment variables are supported.

Environment Variable	Purpose
`BUILD_DEBUG`	If set, a debug version will be built. The packaging script will not run with this var set.
`BUILD_VSPROJ`	If set, Visual Studio project files will be built.

Remember that there's a difference between an unset variable and a variable set to an empty string. SET BUILD_DEBUG="" does not unset the variable. You need to write SET BUILD_DEBUG=.

The .dll files necessary for a release build differ from those needed by a debug build. Therefore you need to make sure you run all scripts with BUILD_DEBUG either defined or undefined, depending on your needs.

Building

With the programs above installed and environment variables set, go into the root folder of the repository and run build_windows.cmd. Compiled binaries along with everything needed to run portable will output to .\bin\win64\AdvancedSettings\.

Contributing

For full details, see CONTRIBUTING.md.

Using with QtCreator

Run build_windows.cmd once and fully build (packaging not necessary) the application. Open the .pro file in Qt Creator. A build and toolchain option should be marked in Qt Creator, with all others unmarked. If it isn't, set the directory to be the root repo directory. You should now be able to compile and run in Qt Creator without issues.

Notice that you may need to redeploy library files if you make large changes (run build_scripts\win\deploy.cmd).

Additionally, you can set Qt Creator to run build_scripts\win\deploy.cmd on compilation in order to ensure that the correct libraries are present. Remember to set or unset BUILD_DEBUG depending on your needs.

Using with Visual Studio

Run build_windows.cmd once and fully build (packaging not necessary) the application with the BUILD_VSPROJ environment variable set. Open the newly created project file. If you compiled a release build (BUILD_DEBUG not set) change the build type to release in Visual Studio. You should be able to compile and run with Visual Studio without issues.

Notice that any new files you add or compiler settings you change will not be backported to the .pro file. Hence it is necessary to manually change the .pro file.