[build] Add CPPJIT_EXTRA_INTERPRETER_ARGS for packagers - #95
Open
guitargeek wants to merge 1 commit into
Open
Conversation
The embedded clang probes well-known prefixes for the host toolchain's headers. Where a distribution does not lay its toolchain out that way -- Nix, Guix, any relocatable prefix -- the probe comes up empty and the interpreter fails at its first #include, with no recourse short of patching the wrapper. Bake the search paths in at configure time instead. CppInterOp still appends CPPINTEROP_EXTRA_INTERPRETER_ARGS after them, so the runtime can add to the baked arguments. The value is escaped for the string literal it lands in, so a Windows include path survives the preprocessor, and a ';' is rejected as CMake's list separator. Report a failed interpreter creation while here: a rejected argument left CreateInterpreter returning nullptr while LoadCppInterOp reported success, and the first code to assume an interpreter segfaulted.
Collaborator
|
I am not sure if deriving the interpreter args from a build time variable is a good idea when it is a run time operation. Then, the interpreter standard becomes a part of how you package cppjit, when it is something that can be dynamically configured. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The embedded clang probes well-known prefixes for the host toolchain's headers. Where a distribution does not lay its toolchain out that way -- Nix, Guix, any relocatable prefix -- the probe comes up empty and the interpreter fails at its first #include, with no recourse short of patching the wrapper. Bake the search paths in at configure time instead. CppInterOp still appends CPPINTEROP_EXTRA_INTERPRETER_ARGS after them, so the runtime can add to the baked arguments.
The value is escaped for the string literal it lands in, so a Windows include path survives the preprocessor, and a ';' is rejected as CMake's list separator. Report a failed interpreter creation while here: a rejected argument left CreateInterpreter returning nullptr while LoadCppInterOp reported success, and the first code to assume an interpreter segfaulted.