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:
> > To be able to do this, BuildStream needs to be able to set an
> > environment variable in the element sandbox corresponding to the
> > digest of an element's artifact designated as "the toolchain". We need
> > to be able to choose the name of the environment variable: in the case
> > of RECC, this would be RECC_REMOTE_PLATFORM_chrootRootDigest. The
> > usual way we would do this is to have this value in a buildstream
> > variable (like the current element-name or max-jobs) and let the user
> > use it to set the appropriate environment variable. However, this
> > can't be done in this case as the CAS digest of the toolchain can only
> > be resolved at staging time.
> >
> > For the actual implementation, I think we can have a new dependency
> > configuration for setting this. BuildElement would implement it, and
> > it can be used by all the build elements. There are some issues to
> > consider for the implementation, but nothing too hard. For instance,
> > currently the only way to get the virtual Directory of an Element's
> > artifact is to stage it (which requires a sandbox). Another one is
> > that setting the environment variables happens at configure_sandbox()
> > time, which is currently before staging.
>
> I got confused on reading this, maybe you can help me understand...
You're right, my proposal is missing an example :)
> 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
[...]
```
This would mark gcc.bst (and possibly its runtime dependencies) as
toolchain (we can mark more than one element this way), and when
preparing the sandbox, it takes all the elements marked as toolchain,
stage them into a single directory and set the environment variable
RECC_REMOTE_PLATFORM_chrootRootDigest to the CAS digest of this
directory.
> Is it something that is the same for an entire build, or is it something
> that changes per element?
For the dependencies (marking a given dependency as part of the
toolchain), it has to be in individual elements. The sandbox
configuration could be made global in project.conf. In both cases, we
can also use include files (though adding dependencies using includes
has some caveats).
> Is the "toolchain" in a build process just the set of build dependencies
> for a given element?
I think this is clearer with the example now. The idea is that not all
build dependencies are part of the toolchain, as otherwise we will
have to rebuild every time and it won't gain us much (it will only be
useful if you change the configuration of the element, or the public
data of its dependencies).
> 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.
I hope this clears up the confusion,
Abderrahim
