build-containers
build-containers copied to clipboard
Update readme
How about some documentation for this repository? I have some questions that can go in the document. I'll squash it once it's all approved.
-
Anything to add, change or remove?
-
Can someone print out
podman images
with the full stack built? I'm only 3/4ths the way through mine. -
How much space does the full stack take? And is that based on using docker, podman/vfs, or podman/overlayfs?
-
Does the order of builds matter? e.g. If someone just wants to build windows/mono, do they need anything prior?
-
My android build just completed, but it's 12.8gb! Does all that stuff need to remain there? It looks like 6.3gb for android-toolchains and 3.4gb for the sdk.
-
What is each docker image for? godot-fedora -> Base OS for other dockers godot-export -> ? godot-mono -> ? godot-mono-glue -> ? godot-windows -> Windows 32/64 and mono godot-ubuntu-32 -> Linux32 and mono godot-ubuntu-64 -> Linux64 and mono godot-android -> Android godot-javascript -> Web export godot-xcode-packer -> Builds MacOS and IOS SDKs (can it be deleted once built)? godot-ios -> IOS godot-osx -> MacOS godot-msvc -> UWP
Ok, well I guess if there are no comments this can be merged.
I updated the commands for build.sh but haven't rebuilt all my dockers yet.
I'd still like to add notes based upon the questions I asked above. Like which dockers would a user use, can any be removed, are they dependent upon the others, etc.
First time attempting to use docker/podman
.
I went through the instructions in this PR, and there's a couple of things which got me confused:
- Only
podman
is currently supported, it seems. - The way I see it, "stepping through" implies that there's a way to interactively skip some builds, I couldn't find a way to do this, so I just disabled some in the
build.sh
.
Additionally, I've installed WSL2 with instructions in https://www.redhat.com/sysadmin/podman-windows-wsl2 and also had to configure podman
in /etc/containers/libpod.conf
(deprecated, but I couldn't get it to override defaults with the suggested alternative, or I simply didn't care much!). In there, added:
cgroup_manager = "cgroupfs"
events_backend = "file"
Also, events_backend
may be events-logger
in previous versions of podman
... Just look podman --help
.
At the end, I think I've managed to build godot-ubuntu-64
image, but couldn't run it under WSL2:
podman run -it --rm localhost/godot-ubuntu-64 /usr/bin/bash
Trying to pull localhost/godot-ubuntu-64...
Get "https://localhost/v2/": dial tcp 127.0.0.1:443: connect: connection refused
Error: unable to pull localhost/godot-ubuntu-64: Error initializing source docker://localhost/godot-ubuntu-64:latest: error pinging docker registry localhost: Get "https://localhost/v2/": dial tcp 127.0.0.1:443: connect: connection refused
That said, I'm sure there's a way to run this properly. Maybe not under WSL2 which is relatively new.
But overall, these instructions are better than mostly an empty README. 🙂
podman version 2.1.1
So you are going to try cross-compiling Godot for 10+ platforms, inside a docker, inside a WSL VM on Windows? Lol. See you in 10 years.
TBH, you should just dual boot. Partition off 10-20gb for linux, then mount your windows partition w/ the Godot source tree on it. Then you can build on either without duplication. I found no end of difficulties of cross-compiling for windows, esp w/ mono, in Linux. For my binaries, I finally just ran my C: installation of windows within a VM in linux, so I could build them in MSVC during the same session as all of the other platforms.
By "stepping through" I meant manually running the individual podman creation lines yourself, one at a time to build the dockers individually.
I believe there was another note or issue where it was confirmed that docker is not / no longer compatible.
It's expected that you'll have to configure podman on your own system. On my ubuntu system the package came properly preconfigured for a ubuntu system, so I only needed to change a few settings as stated. You are running an opensuse implementation installed in an experimental WSL VM. I would expect to have to review and fiddle with all of the default settings. Another reason to use a real linux distro.
For your error, you should list your dockers, then try running the name it shows in the list. In the doc I wrote you can see the name I'm running matches the docker list. Your error suggests it's not recognizing the name you typed in as a local image, and is trying to pull down an image from a remote server (which is your local machine). It may be because your podman is misconfigured, or it could just be a different parameter or identifier is needed.
Yeah, it's not like I'm suggesting to use WSL2, just wanted to document the process I went through. 😛
But, I still tried this approach because I've been successfully compiling Linux, Android, Web builds from within WSL without issues, so there has to be some extra steps that has to be configured, alas my docker knowledge and enthusiasm are not enough to make it work. It's still not ready for public use so I'll just wait for Godot. 🙂
For your error, you should list your dockers, then try running the name it shows in the list. In the doc I wrote you can see the name I'm running matches the docker list. Your error suggests it's not recognizing the name you typed in as a local image, and is trying to pull down an image from a remote server (which is your local machine).
Neither combination of names seemed to work (with/without localhost
).
It may be because your podman is misconfigured
Likely so!
So you are going to try cross-compiling Godot for 10+ platforms, inside a docker, inside a WSL VM on Windows? Lol. See you in 10 years.
Only a year later! 😃
See #74 for my endeavors on native Linux, and thanks for some information you've presented with this PR.
Also note that this PR has merge conflicts due to #72. When comparing #72 and this PR, then this PR has some more information on podman usage specifically, which is useful for beginners (myself included). I think beginners are the first one who'd be using this repository, since build-containers
were presented with an intention that it should be easy to use (eventually).
But I've heard that the container approach will be probably dumped in favor of build toolchains, so I don't know...