<@UB2J9BQA0>: i’ve had a few thoughts about enviro...
# development
w
@hundreds-father-404: i’ve had a few thoughts about environments and remoting: should i add suggestions/a-section to your existing design, or to @ancient-vegetable-10556’s new document?
a
I think Eric’s probably makes more sense
👍 2
unless it’s specifically about how options are modelled
w
yea, won’t be.
@hundreds-father-404: added a section here. basically, i think that we will have a
remote_environment
target, and that to allow for transparently falling back to it, we’ll need more flexible matching.
cc @fast-nail-55400 ^
h
+1. the current implementation should allow that. The matching logic lives inside
EnvironmentNameRequest -> EnvironmentName
w
sounds good. i Suggested one more potentially controversial point at the end of that section
i’m not going to be starting anything in this area, since i need to be working on the backend. but if you’d like me to incorporate the ideas from the Appendix into the rest of the document i can do that, and open some tickets about implementation?
f
fyi I added a comment about having the ability to match against "execution platform" and "target platform" instead of just "platform."
w
thanks: responded
f
do I have the notion of environment "reversed" somehow? how do we select environments in a way that just says "give me a linux target platform"?
is environment akin to Bazel toolchain?
w
how do we select environments in a way that just says “give me a linux target platform”?
@fast-nail-55400: there is no facility for that currently. that’s what i have suggested in this section
is environment akin to Bazel toolchain?
an environment target is roughly equivalent to a toolchain, yes. the difference is that toolchains are decomposed such that you might have “a toolchain to select the JDK” vs a “toolchain to select the C++ compiler”, whereas environments aggregate all of the environment-specific options into an environment target
1
and the “decomposition” occurs via subsystems