Created
April 20, 2016 09:18
-
-
Save jnthn/7843dadbe45e3f56f02f6a679c21f407 to your computer and use it in GitHub Desktop.
This file contains 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
Slide 3: Cross Compiler | |
- The NQP and Rakudo compilers are also cross-compilers by this definition, | |
since their output works on any platform | |
Slide 9: sysroot | |
- So if I follow, this is only relevant to compiling native code, and it says | |
where the headers etc. for that target platform live? | |
Slide 14: | |
- The MoarVM build process builds itself a minilua as a build tool. If I | |
follow, then we'd build it with HOSTCC, for example, but MoarVM itself | |
with CC, which is the cross-compile one | |
- "do not run target artifacts locally" - this one is a little interesting | |
for NQP and Rakudo, since build and target artefacts are byte-for-byte | |
equal. Let's take the Rakudo bootstrap since it's easier than the NQP one | |
(which is self-hosting). We build a bunch of NQP code to get a Perl 6 | |
compiler. We then run that Perl 6 compiler on the built-ins library. How | |
does such bootstrapping play with cross-compiling? Should we, for example, | |
just copy each artefact we produce to another output location? | |
- Rakudo has one bit of C code when building for MoarVM. Since I guess we | |
need to run the Perl 6 compiler on the host, since we can't run any of | |
the artefacts we produce, I understand this to mean that in a cross-comp | |
case we should compile that library for both the host *and* the target? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment