Hi Onur,
On 14/10/2025 4:08 pm, Onur Özkan wrote:
On Tue, 14 Oct 2025 13:58:10 +0200
Miguel Ojeda <[email protected]> wrote:
On Tue, Oct 14, 2025 at 11:45 AM Guillaume Tucker
<[email protected]> wrote:
Add scripts/Makefile.container to wrap the make command in a
container using the CONTAINER= variable to specify the image name.
For example:
make -f scripts/Makefile.container CONTAINER=korg-gcc defconfig
The container image name is entirely arbitrary and the container
tool may be Docker, Podman or any other compatible alternative
specified by the CONTAINER_COMMAND variable. The default is set to
docker for now.
IIUC, this wraps reruns `make` inside the container, but it means
hardcoding a particular tool and path, right? (unless one sets even
more variables)
The cover letter says one can create an alias for this, but one could
also do that for the underlying call anyway, unless I am missing
something. And if we do this, then I would prefer one doesn't need to
type `-f ...`.
Put another way, for a user, what is the benefit of having this extra
way of running in a container? For instance, I could see the benefit
if different tools had different flags or it was a complicated
procedure, but I think at least `podman` shares the flags used here.
Should this instead be a document inside `Documentation/` somewhere
that explains how to do this, pitfalls, advanced options, etc. and
give example command lines for different tools?
If we do end up with `CONTAINER=`, then I think it should make it work
without having to pass `-f ...`, to make it easier. Or, even better,
like the KUnit script, we could have a script that does the right
thing and reads a config from the user, so that one can just type
something like, picking whatever tooling the user configured (e.g.
Docker vs. Podman, default image, etc.):
scripts/container.py defconfig
I think this functionality would be better implemented as a script
(like you mentioned) rather than a Makefile. The current approach is
likely to run into several practical issues (e.g. file permission
mismatches between host and container, the need to manually remove
containers with `docker rm`, etc.) and addressing all of these
reliably in Makefile can become quite messy. Writing a python (or even
perl) script would make it much easier to maintain. Also, it can be
self-documented quite nicely with `scripts/container.py --help` command.
Our emails have crossed - OK I'll take a look into this. I fear a
script is actually going to be more difficult to maintain and will
require additional dependencies on the host i.e. Python. But like I
wrote in my previous email, I'm happy to consider some alternatives
and see if we can find a consensus.
The issue with file ownership can be addressed with user id mapping
in principle. Garbage collecting containers is not something I've
looked into as it's not a new problem compared to starting containers
explicitly. I'll keep these things in mind too when comparing
solutions.
Thanks,
Guillaume
