1
0
mirror of https://github.com/qTox/qTox.git synced 2024-03-22 14:00:36 +08:00
qTox/buildscripts/docker/Dockerfile.windows_builder

246 lines
9.2 KiB
Docker
Raw Normal View History

chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
# Copyright © 2021 by The qTox Project Contributors
#
# This program is libre software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
FROM debian:bullseye-slim
SHELL ["/bin/bash", "-o", "pipefail", "-c"]
ENV DEBIAN_FRONTEND=noninteractive
ARG ARCH
ARG WINEARCH
ENV WINEARCH=${WINEARCH}
RUN dpkg --add-architecture i386 && \
apt-get update && apt-get install -y --no-install-recommends \
autoconf \
automake \
build-essential \
ca-certificates \
cmake \
extra-cmake-modules \
git \
libarchive-tools \
libtool \
nsis \
pkg-config \
python3-pefile \
tclsh \
texinfo \
unzip \
curl \
gnupg \
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
yasm \
zip \
g++-mingw-w64-${ARCH//_/-} \
gcc-mingw-w64-${ARCH//_/-} \
gdb-mingw-w64
RUN curl -L --connect-timeout 10 https://dl.winehq.org/wine-builds/winehq.key | apt-key add -
RUN echo "deb https://dl.winehq.org/wine-builds/debian/ bullseye main" >> /etc/apt/sources.list.d/wine.list
RUN apt-get update && apt-get install -y --no-install-recommends wine-stable
RUN apt-get clean && \
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
rm -rf /var/lib/apt/lists/*
RUN update-alternatives --set ${ARCH}-w64-mingw32-gcc /usr/bin/${ARCH}-w64-mingw32-gcc-posix && \
update-alternatives --set ${ARCH}-w64-mingw32-g++ /usr/bin/${ARCH}-w64-mingw32-g++-posix
COPY download/common.sh /build/download/common.sh
COPY download/download_openssl.sh /build/download/download_openssl.sh
COPY build_openssl_windows.sh /build/build_openssl_windows.sh
RUN mkdir -p /src/openssl && \
cd /src/openssl && \
/build/build_openssl_windows.sh --arch ${ARCH} && \
rm -fr /src/openssl
env PKG_CONFIG_PATH=/windows/lib/pkgconfig
COPY download/download_qt.sh /build/download/download_qt.sh
COPY build_qt_windows.sh /build/build_qt_windows.sh
RUN mkdir -p /src/qt && \
cd /src/qt && \
/build/build_qt_windows.sh --arch ${ARCH} && \
rm -fr /src/qt
COPY download/download_sqlcipher.sh /build/download/download_sqlcipher.sh
COPY build_sqlcipher_windows.sh /build/build_sqlcipher_windows.sh
RUN mkdir -p /src/sqlcipher && \
cd /src/sqlcipher && \
/build/build_sqlcipher_windows.sh --arch ${ARCH} && \
rm -fr /src/sqlcipher
COPY download/download_ffmpeg.sh /build/download/download_ffmpeg.sh
COPY build_ffmpeg_windows.sh /build/build_ffmpeg_windows.sh
RUN mkdir -p /src/ffmpeg && \
cd /src/ffmpeg && \
/build/build_ffmpeg_windows.sh --arch ${ARCH} && \
rm -fr /src/ffmpeg
COPY toolchain/windows-${ARCH}-toolchain.cmake /build/windows-toolchain.cmake
COPY download/download_openal.sh /build/download/download_openal.sh
COPY build_openal_windows.sh /build/build_openal_windows.sh
COPY patches/openal-cmake-3-11.patch /build/patches/openal-cmake-3-11.patch
RUN mkdir -p /src/openal && \
cd /src/openal && \
/build/build_openal_windows.sh --arch ${ARCH} && \
rm -fr /src/openal
COPY download/download_qrencode.sh /build/download/download_qrencode.sh
COPY build_qrencode_windows.sh /build/build_qrencode_windows.sh
RUN mkdir -p /src/qrencode && \
cd /src/qrencode && \
/build/build_qrencode_windows.sh --arch ${ARCH} && \
rm -fr /src/qrencode
COPY download/download_libexif.sh /build/download/download_libexif.sh
COPY build_libexif_windows.sh /build/build_libexif_windows.sh
RUN mkdir -p /src/exif && \
cd /src/exif && \
/build/build_libexif_windows.sh --arch ${ARCH} && \
rm -fr /src/exif
COPY download/download_snore.sh /build/download/download_snore.sh
COPY build_snore_windows.sh /build/build_snore_windows.sh
RUN mkdir -p /src/snore && \
cd /src/snore && \
/build/build_snore_windows.sh && \
rm -fr /src/snore
COPY download/download_opus.sh /build/download/download_opus.sh
COPY build_opus_windows.sh /build/build_opus_windows.sh
RUN mkdir -p /src/opus && \
cd /src/opus && \
/build/build_opus_windows.sh --arch ${ARCH} && \
rm -fr /src/opus
COPY download/download_sodium.sh /build/download/download_sodium.sh
COPY build_sodium_windows.sh /build/build_sodium_windows.sh
RUN mkdir -p /src/sodium && \
cd /src/sodium && \
/build/build_sodium_windows.sh --arch ${ARCH} && \
rm -fr /src/sodium
COPY download/download_vpx.sh /build/download/download_vpx.sh
COPY build_vpx_windows.sh /build/build_vpx_windows.sh
COPY patches/vpx.patch /build/patches/vpx.patch
RUN mkdir -p /src/vpx && \
cd /src/vpx && \
/build/build_vpx_windows.sh --arch ${ARCH} && \
rm -fr /src/vpx
COPY download/download_mingw_ldd.sh /build/download/download_mingw_ldd.sh
COPY build_mingw_ldd_windows.sh /build/build_mingw_ldd_windows.sh
RUN mkdir -p /src/mingw_ldd && \
cd /src/mingw_ldd && \
/build/build_mingw_ldd_windows.sh && \
rm -fr /src/mingw_ldd
COPY download/download_nsisshellexecasuser.sh /build/download/download_nsisshellexecasuser.sh
COPY build_nsisshellexecasuser_windows.sh /build/build_nsisshellexecasuser_windows.sh
RUN mkdir -p /src/nsisshellexecasuser && \
cd /src/nsisshellexecasuser && \
/build/build_nsisshellexecasuser_windows.sh && \
rm -fr /src/nsisshellexecasuser
COPY download/download_msgpack_c.sh /build/download/download_msgpack_c.sh
COPY build_msgpack_c_windows.sh /build/build_msgpack_c_windows.sh
RUN mkdir -p /src/msgpack_c && \
cd /src/msgpack_c && \
/build/build_msgpack_c_windows.sh && \
rm -fr /src/msgpack_c
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
COPY download/download_toxcore.sh /build/download/download_toxcore.sh
COPY download/download_toxext.sh /build/download/download_toxext.sh
COPY download/download_toxext_messages.sh /build/download/download_toxext_messages.sh
COPY build_toxcore_windows.sh /build/build_toxcore_windows.sh
RUN mkdir -p /src/tox && \
cd /src/tox && \
/build/build_toxcore_windows.sh && \
rm -fr /src/tox
RUN mkdir /export && \
cp /usr/${ARCH}-w64-mingw32/lib/libwinpthread-1.dll /export/ && \
cp /usr/lib/gcc/${ARCH}-w64-mingw32/10-posix/libgcc_s_*-1.dll /export && \
cp /usr/lib/gcc/${ARCH}-w64-mingw32/10-posix/libstdc++-6.dll /export && \
cp /usr/lib/gcc/${ARCH}-w64-mingw32/10-posix/libssp-0.dll /export && \
cp /windows/bin/Qt5Core.dll /export && \
cp /windows/bin/Qt5Gui.dll /export && \
cp /windows/bin/Qt5Network.dll /export && \
cp /windows/bin/Qt5Svg.dll /export && \
cp /windows/bin/Qt5Xml.dll /export && \
cp /windows/bin/Qt5Widgets.dll /export && \
cp /windows/bin/avcodec-*.dll /export && \
cp /windows/bin/avdevice-*.dll /export && \
cp /windows/bin/avformat-*.dll /export && \
cp /windows/bin/avutil-*.dll /export && \
cp /windows/bin/libexif-*.dll /export && \
cp /windows/bin/libqrencode.dll /export && \
cp /windows/bin/libsodium-*.dll /export && \
cp /windows/bin/libsqlcipher-*.dll /export && \
cp /windows/bin/libmsgpackc.dll /export && \
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
cp /windows/bin/swscale-*.dll /export && \
cp /windows/bin/libcrypto-*.dll /export && \
cp /windows/bin/libtoxcore.dll /export && \
cp /windows/bin/libopus-*.dll /export && \
cp /windows/lib/libvpx.dll /export && \
cp /windows/bin/OpenAL32.dll /export && \
chore(CI): Use docker for CI scripts Motiviation: * Reproducing issues in CI is currently difficult * Predicting issues in CI is currently difficult if you are not on ubuntu 18.04 * Reproducing issues submitted from other distros is currently done by creating a VM of that distro and building qtox for it locally * Documentation for how to build on different distros is out of date * Issues on non-ubuntu distributions are not caught by CI * Cross compiling for windows locally is not trivial * Iterating when working with custom build scripts is slow, scripts don't necessarily support re-running without re-starting the docker container and re-building qtox again * Updating dependencies is a pain Changes: * docker-compose file has been added to the root of our repo. After `docker compose run --rm ubuntu` (or other supported distros), you are ready to compile and run qtox * Dependencies are owned by dependency install scripts in buildscripts/. This allows us to use the same exact dependencies in our OSX/windows/linux scripts * New docker images have been added for a variety of distributions. These are now run in CI in a variety of configurations * Docker images are cached in CI so rebuild time for the majority of jobs is quite quick * Build scripts have been trimmed to leverage state of docker containers. * Windows build script no longer installs anything, dependencies are now managed by the windows_builder docker images * Build scripts should now be easily re-runnable. Usage is now `docker compose run --rm <image>` and then run the scripts * All artifacts are now uploaded to github after build, this means we can take an appimage/flatpak/exe/dmg for any given PR and try it out without having to build it ourselves Notes: * Docker image size is quite important. We have a maximum of 5GB cache space on github actions. The majority of the linux distro docker images cache at ~300-400MB, which gives us room to test ~6 distros after accounting for the sizes of flatpak/windows docker images * Docker layer ordering is relatively intentional. Approximate order should be that large dependencies that change infrequently should be farther up. This lowers the amount of rebuilding we have to do when dependencies are updated * download_xxx.sh scripts are the cleanest way I could find to implement a shared dependency map between osx scripts and docker containers. Although it would be nice to have a single dependency mapping file, splitting it into individual scripts allows us to only rebuild some docker layers when dependencies are updated. * Github actions are split between docker image building and docker image use. This allows us to re-use the same docker images for multiple jobs, but only build it once * Unfortunately I could not find a way to de-duplicate the stitching between jobs, so we have a lot of copy pasta in that area
2021-11-08 13:27:45 +08:00
cp /windows/bin/libssl-*.dll /export && \
cp /windows/bin/libsnore-qt5.dll /export && \
mkdir -p /export/libsnore-qt5/ && \
cp /windows/plugins/libsnore-qt5/libsnore_backend_windowstoast.dll /export/libsnore-qt5/ && \
cp /windows/bin/SnoreToast.exe /export && \
cp -r /windows/plugins/iconengines /export && \
cp -r /windows/plugins/imageformats /export && \
cp -r /windows/plugins/platforms /export
RUN mkdir -p /debug_export
COPY download/download_mingw_debug_scripts.sh /build/download/download_mingw_debug_scripts.sh
RUN mkdir -p /src/mingw-debug-scripts && \
cd /src/mingw-debug-scripts && \
/build/download/download_mingw_debug_scripts.sh && \
sed -i "s|your-app-name.exe|qtox.exe|g" debug-*.bat && \
cp -a debug-*.bat /debug_export && \
rm -fr /src/mingw-debug-scripts
COPY download/download_gmp.sh /build/download/download_gmp.sh
COPY build_gmp_windows.sh /build/build_gmp_windows.sh
RUN mkdir -p /src/gmp && \
cd /src/gmp && \
/build/build_gmp_windows.sh && \
rm -fr /src/gmp
COPY download/download_libexpat.sh /build/download/download_libexpat.sh
COPY build_libexpat_windows.sh /build/build_libexpat_windows.sh
RUN mkdir -p /src/libexpat && \
cd /src/libexpat && \
/build/build_libexpat_windows.sh && \
rm -fr /src/libexpat
COPY download/download_gdb.sh /build/download/download_gdb.sh
COPY build_gdb_windows.sh /build/build_gdb_windows.sh
RUN mkdir -p /src/gdb && \
cd /src/gdb && \
/build/build_gdb_windows.sh && \
rm -fr /src/gdb && \
cp /windows/bin/gdb.exe /debug_export/gdb.exe
RUN mkdir -p /qtox
WORKDIR /qtox