Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mkosi sandbox should support --runtime-{build-sources,trees,scratch} #3206

Open
septatrix opened this issue Nov 18, 2024 · 1 comment
Open
Labels

Comments

@septatrix
Copy link
Contributor

mkosi commit the issue has been seen with

main

Used host distribution

Fedora 40

Used target distribution

Fedora 40

Linux kernel version used

6.11.6-200.fc40.x86_64

CPU architectures issue was seen on

x86_64

Unexpected behaviour you saw

mkosi sandbox is supposed to provide the same environment as mkosi {qemu,boot,shell} but the runtime mounts do not seem to get applied.

This would be great for more capable mkosi.clangd files (and similar wrapper files). Currently they are implemented as special cases of build scripts though this comes with the disadvantage that other build scripts are still run which can have unexpected side effects. I also think there is no easy way to influence the order of build scripts (by e.g. prefixing files with numbers).

Another disadvantage of the wrapper scripts is that they call mkosi and expect that it is in the path. This might not always be the case as people can invoke it directly though bin/mkosi (here) or .venv/bin/mkosi (unactivated python venv). Furthermore, wrapper scripts make it hard to specify args to mkosi like -C while still allowing for args to the wrapped command clangd --limit-references=0.

With mkosi sandbox this could often be simplified (and a method to obtain the config from inside the sandbox would be nice like $MKOSI_CONFIG in build scripts)

Used mkosi config

No response

mkosi output

No response

@septatrix
Copy link
Contributor Author

septatrix commented Nov 19, 2024

After some discussion my intended use-case for this would still be infeasible after the change though it might still be useful for other scenarios (and for consistency's sake). For my use-case #3208 is better suited

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants