Hello,
On 23/12/2024 17:14, Abderrahim Kitouni wrote:
Hi Sam,
Le lun. 23 déc. 2024 à 10:36, Sam Thursfield
<[email protected]> a écrit :
On 20/12/2024 20:36, Abderrahim Kitouni wrote:
As an author of BuildStream elements, do I need to manually label these
"build elements" to say they're part of the "toolchain"? If so, how do I
know what is the "toolchain" and what is not?
You do not need to "label" the elements as toolchain when making them,
you only need to do it when adding them as dependencies.
I'm thinking about something like:
```
kind: cmake
build-depends:
- filename: gcc.bst
config:
toolchain: true
depends:
- base.bst
- some-library.bst
sandbox:
casd-socket: /run/casd.sock
toolchain-environment: RECC_REMOTE_PLATFORM_chrootRootDigest
Thanks for the example -- this makes things clearer.
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.
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.
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.
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.
It's crucial to know what `toolchain` means in order to correctly label
things -- now I know that it's the concept *as defined by Recc*, I can
look at the Recc docs[1] and I see this:
> When invoked with a C/C++ compilation command...
So that suggests that if I want to use `recc`, I need to label with
`toolchain` any element that installs a binary named `cc` or `c++` or
`gcc` or `g++`... right ?
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`.
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?
Thanks for clarifying everything!
Sam
1. https://buildgrid.gitlab.io/buildbox/buildbox/recc.html
--
Sam Thursfield (he/him), Codethink Ltd.
