Improve toolchain integration #492
Conversation
ehaas
force-pushed
the
toolchain
branch
5 times, most recently
from
6a1a95d
to
af506f9
Compare
ehaas
force-pushed
the
toolchain
branch
3 times, most recently
from
0ee9656
to
14602f5
Compare
Also handle errors properly
Add an explicit uninitialized state so that discovery is only performed once but can be delayed until actually needed, so that errors during discovery (which is only needed for linking) do not affect earlier stages of the pipeline.
Use default initializer instead of init; use constSlice if possible
And store it in the driver since it will be used in multiple places
|
@Vexu Ok I think this is finally ready for review. There's a lot here, would it be easier if I tried to break it up into a bunch of smaller PRs that build on each other? The logic is mostly adapted from clang; with the caveat that there are probably lots of bugs in the translation because I can't really test it on a wide variety of systems. |
There was a problem hiding this comment.
Ok I think this is finally ready for review. There's a lot here, would it be easier if I tried to break it up into a bunch of smaller PRs that build on each other? The logic is mostly adapted from clang; with the caveat that there are probably lots of bugs in the translation because I can't really test it on a wide variety of systems.
Skimming through I didn't spot anything obviously bad, I'm fine with merging it as is and fixing things as they're found unless you want more throughout reviews?
This is not meant to be a general purpose function, so we just require that the caller pass a large-enough buffer for any possible target.
|
Ok, made the suggested changes. I'm ok with merging it as-is (assuming it works on your machine) and then fixing issues as they come up when more people start using it on a broader variety of systems. |
Work in progress - Add some additional arguments to the linker + path discovery for file components
Next step will be figuring out where GCC is installed