Also fix some bugs discovered in the process.
For multi-config generators, this basically just copies the DLLs for
each configuration, and for single-config, due to there being separate
build directories with separate extracted dependencies for each, it
defaults to just one, and will run the script several times if you
manually specify several.
Details include:
* Changing CONFIGURATION from a string to an array called
CONFIGURATIONS. This gets iterated over in a bunch of places.
* Fixing a typo of 'cannot'
* Making the DLL lists arrays per-config, too.
* Some handling for the recursive stuff and a warning if configurations
are set with a multi-config generator.
* Moving the configuration name sanitisation after they've been set.
* Myriad changes to Google Test:
- Build it in a directory specific to the build tools - previously,
having an MSVC 2017 and MSVC 2019 build on the same machine was
impossible if unit tests were on, even though it's allowed otherwise
- Use either Debug or Release Google Test as its finder isn't looking
for RelWithDebInfo or capable of dealing with it if we try and use
it anyway.
- Always build Google Test with MSBuild as it's much less hassle due
to CMake setting up the environment for us. Currently, MSVC always
comes with something that can build solution files, no matter how
you get it, so this shouldn't upset anyone.
- Use CMake's --install mode so we can set the install prefix in the
place that uses it.
- Pass CMake both Debug and Release Google Test instead of risking a
C/C++ library configuration mismatch causing linker and runtime
errors - it'll pick a suitable one for each configuration.
- Pass the library type explicitly as CMake can't cope without a
Release library if you only gave it Debug, due to accessing a
Release-specific variable unconditionally.
* Remove the -legacy flag from vswhere as it's only needed for MSVC
2015, which we don't support any more.
* Fix the -version argument for vswhere as I'd massively cocked it up.
I don't know how that happened as I did test it on a machine with
multiple MSVC versions installed, which was the failure case, but it
didn't fail then.
As we have `set -e`, the error message would never be printed if we
genuinely failed to create the virtualenv, just if we succeeded and the
expected directories didn't exist.
Switches `eval stuff $STRIP` to `run_cmd` as it'll log errors on failure
and eval was breaking commands that ran just fine otherwise.
Don't download aqt wheel from pip and install it in two separate steps.
Upgrade aqt from 0.8 to 0.9.2 as there are bugs with 0.8 that stop Qt
5.15.0 from working for some people.
Fall back to Qt 5.14.2 for 64-bit on MSVC 2017 as the package list is
broken and that specific combination doesn't work right now.
A dummy command was used to check the script would fail if a command was missing.
Not being a real command, it always made the script fail as a command was missing.
We have `set -e` enabled, so normally exit the script if a command fails.
We also had explicit exit code checks in a few places with user-friendly
error messages. These were never printed as the script exited before we
could check the exit code due to a bad exit code.
Otherwise it fails with:
Qt 5.15.0... Exists. CI/before_script.msvc.sh: line 781: cd: MSVC2019_64_Ninja/deps/Qt/5.15.0/msvc2015_64: No such file or directory
* Windows CI: Use OSG 3.4-experimental for 0.46
* Update compiled Windows CI dependencies
Only built and pushed so far, still need to try making full OpenMW
builds with them as well.
* Update missed Bullet version number
* MyGUI uses RelWithDebInfo for Release builds now
* Update Windows CI dependencies, switch Qt install
* Fix aqt retrieval and setup
* Make aqt install output slightly nicer
* Bump to Qt 5.15 for VS2019 support
* Fix FFmpeg and Qt install parts
* Fix OSG plugin DLL copying
* Add CMake flag for double-precision bullet
* Roll back 2019 to Boost 1.71 for CI
* Move aqt into unpack step, to allow manual install
Enable Windows Ninja builds
See merge request OpenMW/openmw!202
(cherry picked from commit e0b352323226ff11e230f6489e826df332fa681a)
c1e673ce Unify path conversion functions
fdf0fdbb Fix NMake with MSVC 2019
bdd4a814 Activate MSVC during CMake setup for NMake
eae41050 Support sourcing
c0d28a0e Warn that MSVC environment will need to be activated
bd16ad62 Ninja
7d57e6e2 Support MSVC 2015
3679d329 Check MSVC activated correctly
ed4b73b8 Fix post-2015 Visual Studio
4ffa116a Print message when it's necessary instead of when it isn't
c6e09461 Add instructions for using VS' non-.sln support
d9bb6e63 Activate MSVC later
9ca26358 Create batch script to activate correct MSVC
61df647d Provide scripts to activate selected MSVC in existing shell without kerfuffle
* use c++11 std::align from <memory>
* for Ubuntu, use gcc5 instead of 4.8
* use travis to set gcc to 5
eval
and sudo
* use eval in .travis.yml
* use gcc-8
* replace precise with trusty llvm toolchain, because we have been using trusty for awhile now
* push things to matrix, so we can support multiple releases if we want
* we should not be allowing for failures, we are ready to start trusting clang and its analyzer
* scan-build was pushed to another package
* use gcc-8 still but wrap in scan-build
* travis.yml cleanup, have output of scripts go to stdout, make search for substring a regex
use double []
fix missing ,
use bash to use regex
black spaces matter
* set human readable names for our various builds, split out our static analysis between openmw and openmw-cs
* test if not set, then set otherwise ignore
* use quotes
* do not eval it, set it in travis env
* no more &&
* what does clang7 have to say?
* use sourceline for now
* use clang-7 instead of clang-7.0
* yes, llvm-toolchain-trusty-7 not llvm-toolchain-trusty-7.0
* for static analysis, openmw is compiled and checked on its own while openmw-cs is build with all the rest. this might change in the future.
and actually do it the other way around
It was only by accident that git bash worked for CI basing on the
"real_pwd()" expression. Replace the dubious replacement pattern with
"cygpath", which is present on git bash, Cygwin, and msys2 alike. In
particular git bash uses msys2 internally.
I was able to confirm a working build under msys2 with a wrapper for
MSVC invocation via the Ninja generator.
