You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a native-image invocation occurs, there are actually two sandbox/temp roots in play: there is Bazel's sandbox and execroot, and the temp path created by native-image, where it places:
Generated C code for the Native Image C API
Built objects / libraries
Native Image's sandbox typically occurs under some directory in the pattern /tmp/SVM-.....
After the compile, native-image copies these back to the output root, where they are surfaced to the Bazel developer. That's how it works now.
However, in more complex circumstances, where a Native Image C API target is using external headers or other resources, the build's posture on disk can be quite confusing: when including a header or some other file, where is it coming from? The Bazel sandbox, or the Native Image sandbox? How does one get files from one sandbox to the other? And so on.
It would be awesome if these rules could integrate Bazel's sandbox with a managed temp path for native-image. This would provide the following benefits:
Clear story about accessing resources in Native Image features and directive classes
Sandbox hacks can be dropped from the rule internals
The full native-image compile state could be inspected in Bazel's sandbox, with files preserved via --sandbox_debug
The text was updated successfully, but these errors were encountered:
- feat: full implementation this time of make variable and location
expansion
- feat: managed build temp directory for `native-image`
Relates-To: #244
Relates-To: #245
Signed-off-by: Sam Gammon <sam@elide.ventures>
When a
native-image
invocation occurs, there are actually two sandbox/temp roots in play: there is Bazel's sandbox and execroot, and the temp path created bynative-image
, where it places:Native Image's sandbox typically occurs under some directory in the pattern
/tmp/SVM-....
.After the compile,
native-image
copies these back to the output root, where they are surfaced to the Bazel developer. That's how it works now.However, in more complex circumstances, where a Native Image C API target is using external headers or other resources, the build's posture on disk can be quite confusing: when including a header or some other file, where is it coming from? The Bazel sandbox, or the Native Image sandbox? How does one get files from one sandbox to the other? And so on.
It would be awesome if these rules could integrate Bazel's sandbox with a managed temp path for
native-image
. This would provide the following benefits:native-image
compile state could be inspected in Bazel's sandbox, with files preserved via--sandbox_debug
The text was updated successfully, but these errors were encountered: