mifr/subsurface
1
0
Fork 0
mirror of https://github.com/subsurface/subsurface.git synced 2024-12-04 16:11:28 +00:00
Code Issues Projects Releases Packages Wiki Activity
subsurface/scripts/docker/mxe-build-container/Dockerfile

76 lines
1.9 KiB
Text
Raw Normal View History

docker-mxe: Make Dockerfile reusable Passing an argument on the docker build command line avoids the need to modify the Dockerfile for each image build. Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2019-01-29 21:58:21 +00:00
# Build the image using the --build-arg option, e.g.:
# docker build -t boret/myimage:0.1 --build-arg=mxe_sha=123ABC456 .
#
build system: Docker image creation Just like Android, Windows binaries are best created in a container. I still need to push the latest version to docker hub and use it on Travis, but this way at least the Dockerfile is here. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2019-01-24 21:45:54 +00:00
GitHub Actions: add two stage MXE container build Based on ideas from Anton - both the basic building of containers in the first place as well as the workaround for the 6h build limit. Because GitHub Actions are limited to 6 hours we split the creation of the MXE container into two steps and push the intermediary container after stage 1 to docker hub. Right now each of the steps takes about 3.5 hours, so hopefully even with changes in the future this will continue to work. This commit also introduces use of docker hub instead of GitHub's own registry (since strangely right now GitHub actions cannot run containers from GitHub's private registry). In order for this to work, we need to have the docker credentials in secrets in GitHub. As a result, only people who can create branches in our repository can easily test changes to the container images. Others can modify the code to use a different docker hub account and provide those secrets in their own GitHub account. Not ideal, but of course we cannot allow every pull request to potentially overwrite docker images in our "official" docker hub account. Suggested-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2019-11-24 21:35:09 +00:00
# Start from Ubuntu
build-system: Docker build for 64bit MXE We previously tried to build the MXE Docker container on GitHub using an Action, but that really didn't work well and was a lot more trouble than it was worth. So this goes back to an offline build mechanism where I simply create an updated Docker image when needed and push that to Docker Hub. But this nearly hides the most interesting change here - we are finally switching to using 64bit binaries on Windows. It's 2020 and fewer than 1% of our users use 32bit Windows machines. We'll need to expand this to be able to have both a 32bit and a 64bit version of Subsurface for Windows. But for now, this solves the problem for 99% of our users. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2020-10-28 21:19:45 +00:00
From ubuntu:20.04
# very often master is broken, so we pass in a known good SHA
docker-mxe: Make Dockerfile reusable Passing an argument on the docker build command line avoids the need to modify the Dockerfile for each image build. Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2019-01-29 21:58:21 +00:00
ARG mxe_sha=master
ENV _ver=${mxe_sha}
GitHub Actions: add two stage MXE container build Based on ideas from Anton - both the basic building of containers in the first place as well as the workaround for the 6h build limit. Because GitHub Actions are limited to 6 hours we split the creation of the MXE container into two steps and push the intermediary container after stage 1 to docker hub. Right now each of the steps takes about 3.5 hours, so hopefully even with changes in the future this will continue to work. This commit also introduces use of docker hub instead of GitHub's own registry (since strangely right now GitHub actions cannot run containers from GitHub's private registry). In order for this to work, we need to have the docker credentials in secrets in GitHub. As a result, only people who can create branches in our repository can easily test changes to the container images. Others can modify the code to use a different docker hub account and provide those secrets in their own GitHub account. Not ideal, but of course we cannot allow every pull request to potentially overwrite docker images in our "official" docker hub account. Suggested-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2019-11-24 21:35:09 +00:00
# update and set up the packages we need for this cross build
build-system/MXE: build with more up to date MXE tools. - use hidapi grantlee and mdbtools from MXE - update MXE version to use QT 5.15, and pull in libzstd and CMake 3.17.3 - fix linking of winmm on windows build with new mxe - add some instructions on building the container - add some new dependancies from QT 5.15 to the packaging - add a patch to MXE to Build qtconnectivity with native-win32-bluetooth [Dirk Hohndel: small refactor] Signed-off-by: Paul Buxton <paulbuxton.mail@googlemail.com> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2020-05-30 11:21:22 +00:00
RUN apt-get update && apt-get upgrade -y && \
build-system: Docker build for 64bit MXE We previously tried to build the MXE Docker container on GitHub using an Action, but that really didn't work well and was a lot more trouble than it was worth. So this goes back to an offline build mechanism where I simply create an updated Docker image when needed and push that to Docker Hub. But this nearly hides the most interesting change here - we are finally switching to using 64bit binaries on Windows. It's 2020 and fewer than 1% of our users use 32bit Windows machines. We'll need to expand this to be able to have both a 32bit and a 64bit version of Subsurface for Windows. But for now, this solves the problem for 99% of our users. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2020-10-28 21:19:45 +00:00
DEBIAN_FRONTEND=noninteractive apt-get install --no-install-recommends -y \
build system: Docker image creation Just like Android, Windows binaries are best created in a container. I still need to push the latest version to docker hub and use it on Travis, but this way at least the Dockerfile is here. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2019-01-24 21:45:54 +00:00
autoconf \
automake \
autopoint \
bash \
binutils \
bison \
bzip2 \
build-system/MXE: build with more up to date MXE tools. - use hidapi grantlee and mdbtools from MXE - update MXE version to use QT 5.15, and pull in libzstd and CMake 3.17.3 - fix linking of winmm on windows build with new mxe - add some instructions on building the container - add some new dependancies from QT 5.15 to the packaging - add a patch to MXE to Build qtconnectivity with native-win32-bluetooth [Dirk Hohndel: small refactor] Signed-off-by: Paul Buxton <paulbuxton.mail@googlemail.com> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2020-05-30 11:21:22 +00:00
ca-certificates \
build system: Docker image creation Just like Android, Windows binaries are best created in a container. I still need to push the latest version to docker hub and use it on Travis, but this way at least the Dockerfile is here. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2019-01-24 21:45:54 +00:00
flex \
g++ \
g++-multilib \
gettext \
git \
gperf \
intltool \
libc6-dev-i386 \
libgdk-pixbuf2.0-dev \
libltdl-dev \
libssl-dev \
build-system/MXE: build with more up to date MXE tools. - use hidapi grantlee and mdbtools from MXE - update MXE version to use QT 5.15, and pull in libzstd and CMake 3.17.3 - fix linking of winmm on windows build with new mxe - add some instructions on building the container - add some new dependancies from QT 5.15 to the packaging - add a patch to MXE to Build qtconnectivity with native-win32-bluetooth [Dirk Hohndel: small refactor] Signed-off-by: Paul Buxton <paulbuxton.mail@googlemail.com> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2020-05-30 11:21:22 +00:00
libtool \
build system: Docker image creation Just like Android, Windows binaries are best created in a container. I still need to push the latest version to docker hub and use it on Travis, but this way at least the Dockerfile is here. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2019-01-24 21:45:54 +00:00
libtool-bin \
libxml-parser-perl \
make \
openssl \
p7zip-full \
patch \
perl \
pkg-config \
python \
ruby \
sed \
unzip \
wget \
xz-utils \
lzip \
MXE Docker build: clean up Dockerfile Instead of trying to do it all in one step rely on --squash to do its job. Don't try to be so aggressive in removing things, it saves very little space and caused builds to fail. This results in version 0.9 of the MXE build container Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2019-05-17 22:55:17 +00:00
scons
GitHub Actions: add two stage MXE container build Based on ideas from Anton - both the basic building of containers in the first place as well as the workaround for the 6h build limit. Because GitHub Actions are limited to 6 hours we split the creation of the MXE container into two steps and push the intermediary container after stage 1 to docker hub. Right now each of the steps takes about 3.5 hours, so hopefully even with changes in the future this will continue to work. This commit also introduces use of docker hub instead of GitHub's own registry (since strangely right now GitHub actions cannot run containers from GitHub's private registry). In order for this to work, we need to have the docker credentials in secrets in GitHub. As a result, only people who can create branches in our repository can easily test changes to the container images. Others can modify the code to use a different docker hub account and provide those secrets in their own GitHub account. Not ideal, but of course we cannot allow every pull request to potentially overwrite docker images in our "official" docker hub account. Suggested-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2019-11-24 21:35:09 +00:00
build-system: Docker build for 64bit MXE We previously tried to build the MXE Docker container on GitHub using an Action, but that really didn't work well and was a lot more trouble than it was worth. So this goes back to an offline build mechanism where I simply create an updated Docker image when needed and push that to Docker Hub. But this nearly hides the most interesting change here - we are finally switching to using 64bit binaries on Windows. It's 2020 and fewer than 1% of our users use 32bit Windows machines. We'll need to expand this to be able to have both a 32bit and a 64bit version of Subsurface for Windows. But for now, this solves the problem for 99% of our users. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2020-10-28 21:19:45 +00:00
# checkout MXE at the right version
GitHub Actions: add two stage MXE container build Based on ideas from Anton - both the basic building of containers in the first place as well as the workaround for the 6h build limit. Because GitHub Actions are limited to 6 hours we split the creation of the MXE container into two steps and push the intermediary container after stage 1 to docker hub. Right now each of the steps takes about 3.5 hours, so hopefully even with changes in the future this will continue to work. This commit also introduces use of docker hub instead of GitHub's own registry (since strangely right now GitHub actions cannot run containers from GitHub's private registry). In order for this to work, we need to have the docker credentials in secrets in GitHub. As a result, only people who can create branches in our repository can easily test changes to the container images. Others can modify the code to use a different docker hub account and provide those secrets in their own GitHub account. Not ideal, but of course we cannot allow every pull request to potentially overwrite docker images in our "official" docker hub account. Suggested-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2019-11-24 21:35:09 +00:00
RUN mkdir -p /win
build-system: switch submodule protocol As of today, GitHub no longer allows the 'git://' protocol, so we need to switch the submodule and our other references to cloning git repos to 'https://' instead. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2022-03-15 20:49:10 +00:00
RUN cd /win ; git clone https://github.com/mxe/mxe ; \
build system: Docker image creation Just like Android, Windows binaries are best created in a container. I still need to push the latest version to docker hub and use it on Travis, but this way at least the Dockerfile is here. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2019-01-24 21:45:54 +00:00
cd mxe ; \
docker-mxe: Make Dockerfile reusable Passing an argument on the docker build command line avoids the need to modify the Dockerfile for each image build. Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2019-01-29 21:58:21 +00:00
git checkout ${_ver} ;
build-system: Docker build for 64bit MXE We previously tried to build the MXE Docker container on GitHub using an Action, but that really didn't work well and was a lot more trouble than it was worth. So this goes back to an offline build mechanism where I simply create an updated Docker image when needed and push that to Docker Hub. But this nearly hides the most interesting change here - we are finally switching to using 64bit binaries on Windows. It's 2020 and fewer than 1% of our users use 32bit Windows machines. We'll need to expand this to be able to have both a 32bit and a 64bit version of Subsurface for Windows. But for now, this solves the problem for 99% of our users. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2020-10-28 21:19:45 +00:00
build-system/MXE: build with more up to date MXE tools. - use hidapi grantlee and mdbtools from MXE - update MXE version to use QT 5.15, and pull in libzstd and CMake 3.17.3 - fix linking of winmm on windows build with new mxe - add some instructions on building the container - add some new dependancies from QT 5.15 to the packaging - add a patch to MXE to Build qtconnectivity with native-win32-bluetooth [Dirk Hohndel: small refactor] Signed-off-by: Paul Buxton <paulbuxton.mail@googlemail.com> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2020-05-30 11:21:22 +00:00
# Patch the qtconnectivity build to explicilty enable native-win32-bluetooth and ensure another
# backend is not picked
build-system: Docker build for 64bit MXE We previously tried to build the MXE Docker container on GitHub using an Action, but that really didn't work well and was a lot more trouble than it was worth. So this goes back to an offline build mechanism where I simply create an updated Docker image when needed and push that to Docker Hub. But this nearly hides the most interesting change here - we are finally switching to using 64bit binaries on Windows. It's 2020 and fewer than 1% of our users use 32bit Windows machines. We'll need to expand this to be able to have both a 32bit and a 64bit version of Subsurface for Windows. But for now, this solves the problem for 99% of our users. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2020-10-28 21:19:45 +00:00
ADD qtconnectivity-1.patch /win/mxe/src/qtconnectivity-1.patch
# Move the settings into place to build everything that we need
# separate download from build so that we can redo the build
ADD settings.mk /win/mxe/settings.mk
MXE Docker build: clean up Dockerfile Instead of trying to do it all in one step rely on --squash to do its job. Don't try to be so aggressive in removing things, it saves very little space and caused builds to fail. This results in version 0.9 of the MXE build container Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2019-05-17 22:55:17 +00:00
RUN cd /win/mxe ; \
build-system: Docker build for 64bit MXE We previously tried to build the MXE Docker container on GitHub using an Action, but that really didn't work well and was a lot more trouble than it was worth. So this goes back to an offline build mechanism where I simply create an updated Docker image when needed and push that to Docker Hub. But this nearly hides the most interesting change here - we are finally switching to using 64bit binaries on Windows. It's 2020 and fewer than 1% of our users use 32bit Windows machines. We'll need to expand this to be able to have both a 32bit and a 64bit version of Subsurface for Windows. But for now, this solves the problem for 99% of our users. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2020-10-28 21:19:45 +00:00
make -j 6 download 2>&1 | tee mxe-build.log
Build static glib under mxe mdbtools only builds static under mxe. This should add static build of glib to the container with the mxe libraries. [Dirk Hohndel: merged with latest version of Dockerfile] Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2019-01-29 16:43:16 +00:00
RUN cd /win/mxe ; \
build-system: Docker build for 64bit MXE We previously tried to build the MXE Docker container on GitHub using an Action, but that really didn't work well and was a lot more trouble than it was worth. So this goes back to an offline build mechanism where I simply create an updated Docker image when needed and push that to Docker Hub. But this nearly hides the most interesting change here - we are finally switching to using 64bit binaries on Windows. It's 2020 and fewer than 1% of our users use 32bit Windows machines. We'll need to expand this to be able to have both a 32bit and a 64bit version of Subsurface for Windows. But for now, this solves the problem for 99% of our users. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2020-10-28 21:19:45 +00:00
make -j 6 2>&1 | tee -a mxe-build.log ;
# for some reason smtk2ssrf needs a static build of mdbtools
RUN cd /win/mxe ; \
make MXE_TARGETS=x86_64-w64-mingw32.static glib mdbtools -j 6 2>&1 | tee -a mxe-build.log ;
RUN apt-get remove -y bison flex gperf libc6-dev-i386 libgdk-pixbuf2.0-dev libxml-parser-perl python ruby xz-utils scons && rm -rf /var/lib/apt/lists/*
build-system: create an MXE docker container for both 32 & 64 bit This should allow us to then do both 32 and 64 bit Windows builds in our CI/CD and of course for our releases. In order to still be able to use this container in a GitHub action, aggressively remove things that we won't need during the build. Since we use the experimental -squash argument during docker build, this should get us a much smaller container image in the end. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2020-10-30 18:15:34 +00:00
RUN rm -rf /win/mxe/pkg /win/mxe/log /win/mxe/docs
Reference in a new issue Copy permalink