win32-clang-msvc has an error when compiling with /WX. The moc_predefs.h
file is not being built correctly, while without /WX it works. The
change should be reverted to enabling /WX for all msvc compilers when
the clang-msvc issue is fixed.
Update path to clang-format in appveyor file
Retry CI on Python script
Python script failed on CI due to run-clang-format.py: error: [Error 5]
Access is denied. Research says attempting again might solve the
problem.
The additional files packaged with the installer have been moved to
their own dir to separate them from the C++ source.
All licenses are now also included in the installer, as per the terms.
The version string in overlaycontroller.h has been updated to 2.8.0.
CLANG_FORMAT_LOC
The path to the bin dir for LLVM can be used for both clang-cl.exe and
clang-format.exe. Changing this will reduce the amount of environment
variables in play, leading to better long term quality.
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.
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.
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.
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).
A CONTRIBUTING file is considered special by Github, being automatically
linked to whenever an attempted pull request is made. Writing the
formatting changes along with how to submit bug reports might seem
fractured, but the special status of the CONTRIBUTING file means that
users are likely to find it. Additionally, links will be added to the
Readme and building_on_windows files.
The appveyor script can not use a single quoted double quotes string,
like '"C:\Spaces are trouble\"', hence the solution of defining an
environment variable.
appveyor.yml has been renamed to .appveyor.yml to keep consistent with
.travis.yml and to be default hidden.
Done in batch script because Powershell requires execution policy to be
changed to run scripts. Therefore batch files are considered to have a
lower barrier for entry.
Clang-msvc has problems with around 400 "-Wexpansion-to-defined" errors
in easylogging++.h. No flags seem to be able to disable this error.
Clang-cl is generally in an awkward halfway place between clang and
msvc.
Msvc has problems with C4127 "conditional expression is constant" in the
"qvarlengtharray.h", hence it being disabled with /wd4127.
Neither msvc* compiler has proper support for disabling errors in
specific files. It's either QMAKE magic or waiting for proper support.
Notice that the class has an identical var that is used in several
places. It is unknown if the original programmer intended to use the
member var in this function, but what is actually being done is a new
var being created, changed and returned. This may not respect the
original intention, but it does preserve the original mechanics.
Parameters with the same name as class members are ripe for introducing
bugs. The fact that the "this->" syntax is optional creates confusion
for maintaining programmers who can only guess at the intention.
Casting to void should shut up GCC about
error: statement has no effect [-Werror=unused-value]
static_cast<void>() is possible for all current types. Supposedly an old
C style cast could also be used, but they should not be used in modern
C++ code.
Vasily
Robin Appelman