cs-shadow commented on issue #1773: URL: https://github.com/apache/buildstream/issues/1773#issuecomment-1688914893
Hello @staehle , Apologies for the late reply but I thought better late than never! > Thinking more about this... Changing the base sandbox to be in "build-depends" makes more sense, because it's not really logical to claim that the x86->arm cross-compiler is a runtime dependency of an aarch64 zlib.so I concur. The build sandbox, and build-related "stuff" in general, are best placed as build-time-only dependencies (aka `build-depends`). > I could pass --build to bst shell, but that argument actually does more than what your docs state. Without it by default, it stages everything as if you're looking at the sandbox after bst build completes, so the artifact results of that build are also placed in the final locations. And with --build, it's like it's just before bst build runs commands. > > So if the sandbox is in the "build-depends", what is the intended use-case for bst shell without the --build option? I can provide some context here. The `bst shell` command has 2 rather distinct use-cases - with and without `--build`: * with `--build` - sometimes called "build shell", this mode is intended to help with debugging build failures. Let's say your build was failing and you wanted to play with some build flags, the build shell allows you to do so in the exact same environment (more or less) as `bst build` would do. As such, it provides all the build dependencies of the product and the sources. (note that runtime dependencies are not provided.) * without `--build` - sometimes called "runtime shell" or just "shell", this mode is intended to debug the built artifacts together with their runtime dependencies. (note that sources are not mounted by default.) With that disclaimer aside, my suggestion for your usecase would be to do one of the following: 1. Instead of running a shell in the sandbox, use the explicit command for testing like `bst shell TARGET -- COMMAND ARGS`. This may not always be possible but works well when testing a CLI of some sort. 2. Use some sort of base OS layer as a runtime dependency. This need not be the whole build sandbox, but at least enough things to be able to run a shell if you're after interactive debugging. It could potentailly be an option to have `bst shell` accept multiple targets. That would make it possible to do something like `bst shell TARGET RUNTIME-TARGET ANOTHER-TARGET -- COMMAND`, in case it's not desirable to permanently add a given runtime dependency. ---- In terms of consistency, both `shell` and `artifact checkout` commands default to `--deps run` as both stage the artifacts in some way. `artifact list-contents` is the outlier here, as it's sort of a plumbing command. Although I can totally see why that might be confusing. ---- Now Coming back to your original questions :) > When doing a "bst artifact checkout", the default argument to "--deps" is "run". Can this be made a user-configurable option so we can set it to "none" by default via https://docs.buildstream.build/master/using_config.html or as a project.conf value? Given this context, would you say this is still needed? > Hi, me again. (If there's a better way for me to submit things like this, let me know. There isn't really a clear "how to contact BuildStream Dev team") For new features, we generally recommend our mailing list as the first port of call. Some details here: https://docs.buildstream.build/master/CONTRIBUTING.html#adding-new-features This is certainly the right place for any bug reports. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
