Hello again, Le mar. 24 déc. 2024 à 11:16, Sam Thursfield <[email protected]> a écrit : > Should the example element also depend on `recc.bst`? Given there is > explicit sandbox config and an explicit `toolchain` flag, it seems we > should make the dependency on Recc also explicit.
It should, I just forgot it. It should also depend on cmake, but you get the idea. > I also start to wonder if this could be done via an element plugin, e.g. > `kind: cmake-recc` instead of `kind: cmake`, to avoid having to > copy-paste the `sandbox` config everywhere. Sure, that also works. I'm not sure whether we can have sandbox configuration as part of plugin yaml as of now, but it shouldn't be too hard to add. > >> Is the "toolchain" in a build process just the set of build dependencies > >> for a given element? > ... > >> Personally when I think of the word "toolchain" I think of compilers, > >> like GCC and Rustc and so on, which might be why I'm confused here. > > > > That's correct. The idea is to have the compiler (and what the > > compiler needs to operate) in this "toolchain". Make it small enough > > so that it is less likely to change, but large enough so that it can > > be used in a sandbox to compile a single file given a source file and > > the headers it needs. > > Until now I had missed that the word `toolchain` is referring to the > concept of "toolchain" *as defined by Recc*. Now it all makes sense. I think it's more the concept of toolchain as defined in bazel ([1], though I wouldn't necessarily recommend you read it if you're not familiar with bazel). But the idea is mostly the same. > Is there a way to make this more obvious? If the variable was called > `recc-toolchain` instead of `toolchain` it would be clearar, but I'm not > sure that's ideal. Except it's not specific to recc. We're hoping to be able to apply this to bazel as well. > It's crucial to know what `toolchain` means in order to correctly label > things Let's take a look at the first email, in particular what I called the "safe way". This is the thing we want to have eventually, but can't do it without changes in buildbox. Based on this, let me try to give a clear definition: The toolchain is whatever subset of the current sandbox is needed to produce the output, that isn't considered an input by your tool. In the case of recc, it will consider the C/C++ source file given to it, and the headers that it includes. Depending on the options given, it can consider either only things that are in the current directory (and so exclude any system header) or all the headers. Depending on the configuration, the toolchain would be either the compiler (including any binaries it calls such as the assembler) and system headers or just the compiler. > Let's say in future Recc gains support for Rust caching, when I update > to the new Recc version, I would also need to label with `toolchain` any > element that installs a binary named `rustc` or `cargo`. Right, except you label a dependency not an element. > A thought experiment that could be useful to nail down the proposal: > let's say I have lots of Fortran code, and my retro hacker friend makes > a program named Fecc, which implements REAPI compiler caching for > Fortran code. > > Could I use both Recc and Fecc in one BuildStream project? What would > that look like? Sure. In all cases, your toolchain would be all the implicit / built-in dependencies that any of your tools don't consider to be part of the input. Such that if we were to stage a separate sandbox with the elements marked as toolchain, you can execute the action that your tool is going to use to cache the result. As I'm writing the above, it occurred to me that I'm implicitly depending on the knowledge of the remote execution specification. It might be a good idea to take a look [2]. HTH, Abderrahim [1] https://bazel.build/extending/toolchains [2] https://github.com/bazelbuild/remote-apis/blob/main/build/bazel/remote/execution/v2/remote_execution.proto#L36
