Info about C program rewrite in Rust

Hi everyone,

I'm a very beginner about rust.
I read the first 20 chapters and I think that is very interesting.
I have written a Linux init system in C language and
I'd like to rewrite it in Rust.
That said, I'd want to ask you some questions:

  1. In this init system, I strongly use
    thread, mutex, signals, unix socket, pipe,
    "select" function to monitor more file descriptors,
    inotify to monitor file system events.
    Does Rust cover them?

  2. I implemented a parser which reads the services configuration files
    that have the typical "Section" and "Property" structure.
    Could you advice me any crates to do that?

Some questions about Cargo.
In this init system I use Meson build system to build and install
the program.
Now, I'd to replicate that with Cargo.
I need to run some tasks at compile time and the build script
seems to satisfy this need.

  1. In Meson, I can access to the system directories via get_option('sbindir'), get_option('datadir') etc..
    How can I access in the build script to these directories or what is the Cargo approach to that?
  2. Basically, a C header is generated with these paths as macros that the program read it when starts.
    How can I replicate with Cargo?
  3. About the installation the program, in Meson I install bash completions, man pages, icons, etc in those paths manually.
    How should be done with Cargo?

Thanks in advance.

1 Like
  1. Rust has intentionally small standard library. It has some wrappers for pthreads and Linux mutexes, but for anything non basic you do things in Rust the same way you would do them in C, calling the same C functions or kernel syscalls. There are crates like nix that wrap C APIs to be more convenient to use from Rust. But generally there's nothing Rust-specific here.

  2. It depends how serious you want to be with the parser. There are parsers like nom if you're inventing a new file format. Or you can use something like serde-yaml or toml.

  3. Cargo just builds Rust binaries or static libraries, and nothing else. It has no ability to build other things or properly interact with the system. cargo build is more like gcc -o than Meson. You still need Meson or make or something else to operate on anything outside of the Cargo's target/ directory.

1 Like

Thanks

The standard crate for epoll-like things is mio.

(Or to use async.)

4 Likes

Sorry for the stupid question.
what happens when anyone tries to install a crate which use meson, make or other via cargo install ?
I can guess that cargo will compile the sources, but, who/what will invoke meson (in this case) to complete the installation ?
The build script (build.rs) will do that ???

cargo install will not actively look for other build systems. It will not run make for you. Cargo won't "compile the sources", either – Cargo is not a compiler, and if you need to use any other compiled language in your project, you'll need an appropriate compiler.

Any customization that entails basically anything outside building a pure Rust codebase will have to happen in the build script or be entirely external to Rust tooling.

cargo install is very primitive. It's almost like gcc *.c -o ~/.cargo/bin/<name>. It's just a quick hack for very basic developer-oriented small command-line utilities. It's unsuitable for distribution of more complex software or desktop applications. It always builds from source, and there's no ability to distribute precompiled code via cargo install.

Cargo doesn't know about existence of any other build systems, and won't run any. It doesn't integrate with anything. If your project needs to make and install man pages or bundle any other files, it's simply outside of cargo install abilities. To properly distribute software you'll need to use something else, like a deb or RPM package, or zip it all up yourself after running cargo build --release for just the exe.

There are some crates that run cmake from build.rs, but this is invisible to cargo, and it's useful only for static libraries. It relies on user already having cmake installed, and will break otherwise. Same goes for meson. Note that build.rs runs before the executable is built, and there's no place to put man pages. If you have man pages to build, you can't use cargo install for that.

At the moment, I build the program trought two steps:

cargo build (which will compile the binaries and the library)

After that, I run as root user:

meson setup ...
meson compile ...
meson install ...

Meson will install, man pages, bash completions, icons, mime types etc. in the system directories.
Maybe a post-build.rs file could call that stuff after the build ....
Would be nice.
Anyway, the baddest case this eventual crate will cannot be published.
Eventual linux distros or users which want to install it, should have to build and install in this way or packaging it in their format (deb, rpm and so on) which is pretty simple.

Have you tried running Cargo directly from Meson? That's what GNOME does.

Edit: this one builds a static library then uses it as a dependency of a binary:

1 Like

The issue of post build scripts in Cargo has stalled terribly, and may never happen.

So for now think of cargo more like calling gcc, rather than a build system or package manager. You wouldn't expect gcc to do setup and installation for you.

I didn't even know there was an open issue. As I said at the beginning of the thread, I'm completely new to this world. I'm just here to gather as much information as possible before any development.

Thanks for your advice.
This is an alternative to that I already do but I'm wondering: "If i want to publish a similar crate then what happens when an user run cargo install your_crate ?"
At the moment, I only can understand these crates cannot be installed in this way and thus neither published regardless from that you suggest me.

That's correct. cargo install should not be thought of as a general-purpose installation tool, given its current capabilities; think of it primarily as a way for Rust users to install simple dev-tools written in Rust.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.