Open casey opened 5 years ago
Is there no facility in Rust to access C object (C FFI?) to directly manipulate busybox? Also a facility to embed such C objects? Not idea for certain but would that even be an option?
Rust actually has excellent C FFI facilities, and it's possible to dynamically link C objects to rust objects. My main concern with linking a C library is that I'll ultimately have to maintain and debug that C library, and that it will complicate building and deploying just to different platforms. It's been very easy to produce binaries for different systems thus far, and my experience with C has been that it isn't nearly as easy to do so.
An additional issue with BusyBox is that it's GPL licensed, while just is released into the public domain via CC0, and integrating BusyBox would force the whole of Just to be GPL licensed.
Ah, that makes sense. I'm not sure but I believe cross compiling in Rust is probably about as easy as it is in Go, which is dead simple. But one of the reasons I've yet to get very far in C is the cross-compiling toolchain rabbit hole you have to dive into. After contemplating that sparingly over the last 30 years or so I might be up to the task mentally in a few more years. 😉
GPL, so open and free it can't be used with anything else. Including other OS licenses. Give me MIT, CC, or almost any other open source license, thank you. But that's the least of the problem I'd guess. The C nightmare is just another beast entirely. Thanks for the clarification. 😀
Toybox is worth a mention here; I think it would be an excellent candidate for this.
It's BSD Zero Clause licensed, and super easy to compile:
$ make defconfig toybox CFLAGS="--static" CROSS_COMPILE=x86_64-linux-musl-
$ ldd toybox
not a dynamic executable
It looks like it would be pretty easy to compile it as a static lib and call into it from Just too.
I have never tried to either compile or xcompile it for Windows however.
Edit: I took a quick look into it and it seems there are a number of POSIX headers used that block full compilation with x86_64-w64-mingw32-gcc
. I don't think this is totally insurmountable - depending on the "toys" that use those APIs it may be possible to ship a Windows compatible version that simply omits them.
Toybox definitely seems like a good option, although I'm hesitant to add a non-rust dependency, since it complicates builds and distribution. One intermediate step would be adding instructions, either in the readme or in an example justfile, for using the shell
setting to use toybox as the default shell, which would make just usable on systems where it was installed.
It would be ideal if just included a shell and userland, so it would be fully usable without any dependencies. This is mostly waiting for a busybox clone to be written in Rust, since writing our own shell and utilities would be a gargantuan undertaking.