> I’d like a bit more flexibility in specifying what I want cargo to do.<p>Check out Bazel for Rust.<p>It allows:<p>* caching of artifacts.<p>* shareable caches between {developers, build jobs} based on hashes.<p>* remote distributed builds (on very many cores).<p><a href="https://github.com/google/cargo-raze" rel="nofollow">https://github.com/google/cargo-raze</a>
I feel some of the OP points. I was working on a profiling agent lately, and one of the issues was running it on multiple platforms (just the four big ones linux/mac-x86/arm) on FFI (because it'll be run directly from python/ruby/etc...) and <i>preferably</i> having the thing just work without having to install or configure any dependencies.<p>Like OP I hit two walls: libunwind, and linking. For libunwind, I ended up downloading/compiling manually; and for linking there is auditwheel[1]. Although it is a Python tool, I did actually end up using it for Ruby (by creating a "fake python package", and then copying the linked dependencies).<p>It was at that time that I learned about linking for dynamic libraries, patchelf and there is really no single/established tool to do this. I thought there should be something but most people seem to install the dependencies with any certain software. I also found, the hard way, that you still have to deal with gcc/c when working with Rust. It does isolate you from many stuff, but for many things there is no work around.<p>There is a performance hit to this strategy, however, since shared dynamic libraries will be used by all the running programs that need them; whereas my solution will run its own instance. It made me wonder if wasm will come up with something similar without affecting portability.<p>Finally, the project is open source and you can browse the code here: <a href="https://github.com/pyroscope-io/pyroscope-rs" rel="nofollow">https://github.com/pyroscope-io/pyroscope-rs</a><p>[1]: <a href="https://github.com/pypa/auditwheel" rel="nofollow">https://github.com/pypa/auditwheel</a>
Is compiling once and running on 6 platforms really that compelling? One of Rust’s super powers is that it’s really easy to write code once that can be compiled N times for N platforms without making any changes.<p>I’m all about writing code once. But compiling a few times doesn’t seem like that big of a deal to me?<p>The article says it runs on “six operating systems” but I can’t find them listed?
I’ve found rust incredibly portable. I’ve hacked around running the same server side app on the web (WASM), PC/Mac/Linux, iOS, and Android. Another project is a web app running on iOS and Android leveraging a SQLite DB.
<p><pre><code> I’d change a configuration flag, some part of std would break because my
flag was wrong, and I’d learn something new about Rust and how std worked.
</code></pre>
The project was probably worth doing just because of this. Breaking things in a safe environment is such a great way to learn how it all works.
While I love this sort of portability and in particular how it just makes Rust even more useful to me.<p>The library this is built on does have a bit of a weakness with respect to GUI software <a href="https://github.com/jart/cosmopolitan/issues/35" rel="nofollow">https://github.com/jart/cosmopolitan/issues/35</a> if this can be fixed this will be an amazing tool for building simple cross platform utilities and tools.
Aside form neatness factor and hacker street cred, I don't exactly get the practical point for the vast majority of software. What am I to do with such a binary? Do I put it live on my website and allow my clients to download it? If I leave it with an .exe extension so that it runs in the Windows shell, wouldn't that confuse users of other platforms? What if I need a directory structure as 99% of programs do? Do I use a zip or a tgz? In the first case, how do I preserve permissions on Unix targets? Do I need to instruct my clients into how to use tgz on the command line and/or create permissions?<p>Software distribution is by its nature a very platform specific problem; even if we accept the premise of an x64 world, an universal binary solves just a very small portion of the practical problems of portable deployment.<p>Ironically, the best use case I can imagine is creating an universal binary installer that can run on any Unix system and then proceed to make platform-specific decisions and extract files contained in itself, sort of like Windows binary installers work. But that's an utterly broken distribution model compared to modern package managers.
Just one question, as suggested by the title: the rust compiler itself could be made portable using this? I guess not, because of its use of multi-threading.
> I just built a Rust executable that runs on six operating systems<p>I help maintain a kernel in C that runs on nine architectures, some of which don't even have LLVM backends, much less stable rust toolchains.<p>"Portable" means rather different things. This blog post is focused on the easy stuff.