hipnosuer
/
Zuma
forked from ShuriZma/suyu
1
0
Fork 0
Code Pull Requests Activity
Zuma/.ci/scripts/windows/docker.sh

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

67 lines
1.8 KiB
Bash
Raw Normal View History

Finalize Azure Pipelines Definitions d
2019-07-14 01:34:40 +00:00
#!/bin/bash -ex
chore: make yuzu REUSE compliant [REUSE] is a specification that aims at making file copyright information consistent, so that it can be both human and machine readable. It basically requires that all files have a header containing copyright and licensing information. When this isn't possible, like when dealing with binary assets, generated files or embedded third-party dependencies, it is permitted to insert copyright information in the `.reuse/dep5` file. Oh, and it also requires that all the licenses used in the project are present in the `LICENSES` folder, that's why the diff is so huge. This can be done automatically with `reuse download --all`. The `reuse` tool also contains a handy subcommand that analyzes the project and tells whether or not the project is (still) compliant, `reuse lint`. Following REUSE has a few advantages over the current approach: - Copyright information is easy to access for users / downstream - Files like `dist/license.md` do not need to exist anymore, as `.reuse/dep5` is used instead - `reuse lint` makes it easy to ensure that copyright information of files like binary assets / images is always accurate and up to date To add copyright information of files that didn't have it I looked up who committed what and when, for each file. As yuzu contributors do not have to sign a CLA or similar I couldn't assume that copyright ownership was of the "yuzu Emulator Project", so I used the name and/or email of the commit author instead. [REUSE]: https://reuse.software Follow-up to 01cf05bc75b1e47beb08937439f3ed9339e7b254
2022-05-15 00:06:02 +00:00
# SPDX-FileCopyrightText: 2019 yuzu Emulator Project
# SPDX-License-Identifier: GPL-2.0-or-later
ci/windows: Build using Clang Uses the MinGWClangCross toolchain script to build yuzu. Disables our bundled SDL2 to use the system ones that have been modified to not use `-mwindows`. Also set's `-e` to stop the script on an error (as opposed to packaging nothing). Uses LLVM's linker for linking yuzu. Adds -femulated-tls due to a libstdc++ incompatibility between GCC and Clang in vulkan_common.
2022-05-29 07:35:08 +00:00
set -e
CI: Use GitHub Actions to check pull requests
2021-12-23 06:31:57 +00:00
#cd /yuzu
Finalize Azure Pipelines Definitions d
2019-07-14 01:34:40 +00:00
CI: fix caching
2021-12-24 01:23:02 +00:00
ccache -sv
Finalize Azure Pipelines Definitions d
2019-07-14 01:34:40 +00:00
CI: Use GitHub Actions to check pull requests
2021-12-23 06:31:57 +00:00
mkdir -p build && cd build
ci/windows: Split up cmake command Improves readability.
2022-05-27 01:23:11 +00:00
cmake .. \
-DCMAKE_BUILD_TYPE=Release \
ci/windows: Revert to using GCC for MinGW builds Using MinGW in the future may not be ideal as it does not work very well with crash dumps (#8682). Switch back to GCC on MinGW. This also gives CI a way to check GCC 12 (as of writing, or whatever version of mingw-gcc Arch happens to be shipping on a given week).
2022-10-09 17:56:31 +00:00
-DCMAKE_TOOLCHAIN_FILE="${PWD}/../CMakeModules/MinGWCross.cmake" \
CI: Use GitHub Actions to check pull requests
2021-12-23 06:31:57 +00:00
-DDISPLAY_VERSION="$1" \
ci/windows: Split up cmake command Improves readability.
2022-05-27 01:23:11 +00:00
-DENABLE_COMPATIBILITY_LIST_DOWNLOAD=ON \
-DENABLE_QT_TRANSLATION=ON \
-DUSE_CCACHE=ON \
ci/windows: Build using Clang Uses the MinGWClangCross toolchain script to build yuzu. Disables our bundled SDL2 to use the system ones that have been modified to not use `-mwindows`. Also set's `-e` to stop the script on an error (as opposed to packaging nothing). Uses LLVM's linker for linking yuzu. Adds -femulated-tls due to a libstdc++ incompatibility between GCC and Clang in vulkan_common.
2022-05-29 07:35:08 +00:00
-DYUZU_USE_BUNDLED_SDL2=OFF \
-DYUZU_USE_EXTERNAL_SDL2=OFF \
ci,CMake: Drop Conan support for vcpkg Between packages breaking, Conan always being a moving target for minimum required CMake support, and now their moves to Conan 2.0 causing existing packages to break, I suppose this was a long time coming. vcpkg isn't without its drawbacks, but at the moment it seems easier on the project to use for external packages. Mostly removes the logic for Conan from the root CMakeLists file, leaving basic find_package()'s in its place. Sets only the find_package()'s that require CONFIG mode as necessary. clang and linux CI now use the vcpkg toolchain file configured in the Docker container when possible. mingw CI turns off YUZU_TESTS because there's no way on the container to run Windows executables on a Linux host anyway, and it's not easy to get Catch2 there.
2022-07-22 04:51:01 +00:00
-DYUZU_TESTS=OFF \
ci/windows: Build using Clang Uses the MinGWClangCross toolchain script to build yuzu. Disables our bundled SDL2 to use the system ones that have been modified to not use `-mwindows`. Also set's `-e` to stop the script on an error (as opposed to packaging nothing). Uses LLVM's linker for linking yuzu. Adds -femulated-tls due to a libstdc++ incompatibility between GCC and Clang in vulkan_common.
2022-05-29 07:35:08 +00:00
-GNinja
ninja yuzu yuzu-cmd
Finalize Azure Pipelines Definitions d
2019-07-14 01:34:40 +00:00
CI: fix caching
2021-12-24 01:23:02 +00:00
ccache -sv
Finalize Azure Pipelines Definitions d
2019-07-14 01:34:40 +00:00
echo "Tests skipped"
#ctest -VV -C Release
echo 'Prepare binaries...'
cd ..
mkdir package
Fixed packaging on some systems with different QT5 path
2020-04-23 18:32:16 +00:00
if [ -d "/usr/x86_64-w64-mingw32/lib/qt5/plugins/platforms/" ]; then
ci: windows: Copy the styles directory when packaging Qt can make use of qwindowsvistastyle.dll if present, and our MinGW container has the library, but it was not being copied during the packaging process. Thus, yuzu looked like a Windows 98 application when using the PR-verify artifacts. This copies over the DLL during packaging, for that sweet-sweet Windows Vista style. In addition, set the Qt plugins path instead of the plugins/platforms path. This way we can use the directory directly, rather than appending a `..` everytime we need something just outside of it.
2021-06-19 09:24:56 +00:00
QT_PLUGINS_PATH='/usr/x86_64-w64-mingw32/lib/qt5/plugins'
Fixed packaging on some systems with different QT5 path
2020-04-23 18:32:16 +00:00
else
#fallback to qt
ci: windows: Copy the styles directory when packaging Qt can make use of qwindowsvistastyle.dll if present, and our MinGW container has the library, but it was not being copied during the packaging process. Thus, yuzu looked like a Windows 98 application when using the PR-verify artifacts. This copies over the DLL during packaging, for that sweet-sweet Windows Vista style. In addition, set the Qt plugins path instead of the plugins/platforms path. This way we can use the directory directly, rather than appending a `..` everytime we need something just outside of it.
2021-06-19 09:24:56 +00:00
QT_PLUGINS_PATH='/usr/x86_64-w64-mingw32/lib/qt/plugins'
Fixed packaging on some systems with different QT5 path
2020-04-23 18:32:16 +00:00
fi
Finalize Azure Pipelines Definitions d
2019-07-14 01:34:40 +00:00
find build/ -name "yuzu*.exe" -exec cp {} 'package' \;
# copy Qt plugins
mkdir package/platforms
ci: windows: Copy the styles directory when packaging Qt can make use of qwindowsvistastyle.dll if present, and our MinGW container has the library, but it was not being copied during the packaging process. Thus, yuzu looked like a Windows 98 application when using the PR-verify artifacts. This copies over the DLL during packaging, for that sweet-sweet Windows Vista style. In addition, set the Qt plugins path instead of the plugins/platforms path. This way we can use the directory directly, rather than appending a `..` everytime we need something just outside of it.
2021-06-19 09:24:56 +00:00
cp -v "${QT_PLUGINS_PATH}/platforms/qwindows.dll" package/platforms/
cp -rv "${QT_PLUGINS_PATH}/mediaservice/" package/
cp -rv "${QT_PLUGINS_PATH}/imageformats/" package/
cp -rv "${QT_PLUGINS_PATH}/styles/" package/
Finalize Azure Pipelines Definitions d
2019-07-14 01:34:40 +00:00
rm -f package/mediaservice/*d.dll
for i in package/*.exe; do
# we need to process pdb here, however, cv2pdb
# does not work here, so we just simply strip all the debug symbols
x86_64-w64-mingw32-strip "${i}"
done
video_core/codecs: (re-spin) refactor ffmpeg searching and handling
2021-12-15 08:10:07 +00:00
python3 .ci/scripts/windows/scan_dll.py package/*.exe package/imageformats/*.dll "package/"
ci/windows: Copy downloaded FFmpeg libraries Copies FFmpeg libraries that were downloaded during the CMake configuration. Fixes dynamic linking issues with the MinGW builds.
2021-02-05 18:51:36 +00:00
# copy FFmpeg libraries
EXTERNALS_PATH="$(pwd)/build/externals"
video_core/codecs: (re-spin) refactor ffmpeg searching and handling
2021-12-15 08:10:07 +00:00
FFMPEG_DLL_PATH="$(find "${EXTERNALS_PATH}" -maxdepth 1 -type d | grep 'ffmpeg-')/bin"
ci/windows: Copy what of FFmpeg not already present Prevents overwriting libwinpthreads.dll when one should already be present from the first DLL search.
2022-07-06 02:32:12 +00:00
find ${FFMPEG_DLL_PATH} -type f -regex ".*\.dll" -exec cp -nv {} package/ ';'
externals: libusb: Use autotools for MinGW After updating to 1.0.24, MinGW fails to build libusb as a result of numerous errors. So we build libusb their way and let them update the nontrivial stuff. This only applies to MinGW: the old path is still in use for Linux toolchains as well as MSVC. This will dynamically link libusb, since I hit build errors with the old way we used to resolve the conflict with SDL2.
2021-05-31 02:26:06 +00:00
# copy libraries from yuzu.exe path
find "$(pwd)/build/bin/" -type f -regex ".*\.dll" -exec cp -v {} package/ ';'