Maybe this compiler could help with bootstrapping the official rust compiler. At the moment, it seems to be quite a mess for packagers. Rust is written in Rust, but also needs cargo to build, which is also written in Rust. To break this circular dependency chain, you need to have pre-compiled binaries first in order to bootstrap the build process.
I've been beating my head against the wall for weeks trying to compile rustc/cargo on Openindiana. I want it so that I can compile a recent version firefox and/or thunderbird for Openindiana, both of which require rustc and cargo.
The typical route is to cross compile a compiler and cargo on another platform and then run the resulting binary. Is that approach infeasible for Openindiana?
C compilers are ubiquituous. Name a platform which does not have at least one C compiler. Rust might come into such a position at some later time as well, but until then at least a transitional solution besides cross-compiling would make packaging easier and reproducible.
Really, the solution is just to make cross compiling as easy as any other kind. Compilation is basically a pure function, so by rights compilers with different targets should be drop-in replacements of each other.
Exactly. There's no reason a compiler should take any input but the source (maybe some config) nor have any output but the translated code. There's no dependence on running on a particular piece of hardware in this equation. Just run the codegen for platform Y on platform X.
Sure, I guess in the 10,000 foot view those look like source code :). But there's no fundamental reason you can't have libraries for platform X merely present on a platform Y system, it's just inconvenient today. That's the point I'm really trying to get at.
I'll admit I don't know a whole lot about compilers but don't most of them do optimizations and other changes based on the CPU like its architecture, cache size, and instruction set? That may be what GP is getting at.
Stuff like LLVM, and emscripten exist though so it's probably not as big of a deal as they say.
Sure, based on the target CPU. But there's no fundamental reason I can't do all those optimizations for, say, x86 in a compiler that happens to be running on an Arm CPU. As far as the compiler is concerned it's all just data that gets stuffed in files, just like any other software.
The super-easy cross compilation in go is one of the best parts. Every install comes with the capacity to compile to every go target with no differences in input except setting it by name.
This is really something more languages should strive for.
> This is really something more languages should strive for.
Most languages these days obviate cross-compilation in the first place by being interpreted. Of the languages that remain, the natively-compiled ones, most haven't gone to Go's lengths of writing a custom libc, which is emphatically not recommended for both Windows and Mac (the syscall interfaces aren't stable, and this has broken Go code in the past: https://github.com/golang/go/issues/16272 ). And gc, the primary Go compiler and the one with out-of-the-box cross-compilation, supports relatively few platforms (I count 11, whereas rustc looks like it supports 50-70 platforms). You can use gccgo to get more platforms, but AFAICT gccgo's cross-compilation story isn't nearly as nice: https://github.com/golang/go/wiki/GccgoCrossCompilation .
For Rust, cross-compilation looks like this:
1. Install the libc for the target system, and, if necessary, a compatible linker.
Well, it's not just data - it's also frequently pointers or labels to code in dynamically imported libraries; things which can't always be calculated without the exact library being used on hand.
Be careful, let's not forget the lesson of Ken Thompson's Reflections on Trusting Trust. It's more accurate to say that compilation is a function that takes two arguments: the source code, and the compiler itself; this is how trusting-trust attacks propagate despite total absence from the source code.
You're being pedantic, but your pedantry is incorrect, so allow me to be pedantic in correcting you :p. The output of all pure functions depends on the function and its inputs; this isn't more true for compilers than, say, addition. The problem with Trusting Trust is that the function isn't practically inspectable, not that the function is impure. A trusting trust compiler is still pure.
A functionally pure compiler would always provide the same output for the given source code. The challenges in creating repeatable builds of highly popular open source projects shows that the average compiler is anything but functionally pure. The global state of the system running the compiler has a huge impact on the output of the compiler.
No, it's not obvious what the issue is. If you want to compile a C compiler, you need a C compiler binary. If you want to compile a rust compiler, you need a rust compiler binary. It's the exact same issue, but people don't whine about the C compiler, probably because it's been that way for 50 years.
No, they use C++ even for the C front-end. But you are right, you can still see its C past in the source code.
What's important though is that the GCC devs actively try to avoid the newest C++-features, this allows it to compile current GCC-trunk even with very old GCC-Releases. IIRC even GCC 4.3 (released in March 2008) is able to compile current trunk (GCC 8.0).
This is somewhat different for Rust, where I think the current policy is that master needs to compile with last released version (releases every 6 weeks and just to make it clear: Rust is written in Rust). Before that, the compiler was updated even more frequently. Bootstrapping Rust from 0 therefore is quite hard, since Rust is far from being as ubiquitous as C/C++-compilers. Even if you already have a rustc on your system, it's not unlikely that it is too old for compiling Rust-master. The first Rust-compiler was written in OCaml, so you need to compile that first, then compile Rust commit-for-commit until you reach current master. This could take quite some time. IMHO this is why mrustc is great, since you just compile current master (if it supports all features) with it and then use the generated compiler to compile Rust.
Any carefully written C program that doesn't use certain C99 an C11 things can be said to be C++.
My language implementation compiles as C and C++. Every so often I build it as C++ (like before releases) to check for regressions and flush out any issues caught by the C++ compiler.
I don't think of it as "written in C++", though it is not technically a false statement.
All Scheme programs are really written in Common Lisp; they just need a suitable library of macros and functions ...
MSVC. Yeah, Windows isn't a "distro" but it is a major OS and MSVC is a pretty major compiler. But it's binary only so there's no need to bootstrap it unless you're working at MS.
Speaking from personal experience, that can be quite painful. Being able to build rust and cargo, even if only for bootstrapping when porting, would truly be a wondrous thing.
Why, we could always use emscripten to compile rustc to JavaScript and use that for bootstrapping!
On a more serious note, ghc at least solved this problem by allowing you to compile Haskell to C (-fvia-C). Writing a naive C code generator from whatever your backend is using is probably not that hard.
Go bootstrap uses Go1.4 which compiler is written in C. So: compile Go1.4 and use that to compile the Go 1.X compiler (I don't know but multiple steps might be necessary).
Of the distros, Fedora has the strictest compiler bootstrapping policy, and Fedora seems to be doing great with Rust packaging (for a number of CPU architectures).
