Pages
  • life with BSD
  • 2025-07-31 Fixing jujutsu and leaky ascii escape sequences on FreeBSD
  • 2025-07-31 Swift now available as a package for FreeBSD
  • 2025-07-28 The FreeBSD project clarifies its stance on gen-ai powered contributions
  • 2025-07-28 The rustup question
  • 2025-07-08 Goodbye old friend, a tale
  • 2025-06-30 Configuring FreeBSD to network with a postmarketos phone over usb
  • 2025-06-25 swift (re)lands in the FreeBSD ports tree
  • 2025-06-24 typst a rust powered typesetting tool aiming at latex
  • 2025-06-19 Open Source Two Worlds thoughts
  • 2025-06-14 Taking a look at repolocli
  • 2025-06-09 Zig master builds now with FreeBSD support
  • 2025-06-07 Finding rust dependencies in Makefile.crates
  • 2025-06-05 Ripgrep or ripgrep-all
  • 2025-06-02 Ripgrep a nice Rust utility for ports spelunking
  • 2025-05-31 Get started with gpui on FreeBSD
  • 2025-05-29 Query freshports with Deno
  • 2025-05-27 Trying out Defuddle an npm tool via Deno
  • 2025-05-25 Deno for FreeBSD
  • 2025-05-23 A new beginning
life with BSD
  • life with BSD
  • 2025-07-31 Fixing jujutsu and leaky ascii escape sequences on FreeBSD
  • 2025-07-31 Swift now available as a package for FreeBSD
  • 2025-07-28 The FreeBSD project clarifies its stance on gen-ai powered contributions
  • 2025-07-28 The rustup question
  • 2025-07-08 Goodbye old friend, a tale
  • 2025-06-30 Configuring FreeBSD to network with a postmarketos phone over usb
  • 2025-06-25 swift (re)lands in the FreeBSD ports tree
  • 2025-06-24 typst a rust powered typesetting tool aiming at latex
  • 2025-06-19 Open Source Two Worlds thoughts
  • 2025-06-14 Taking a look at repolocli
  • 2025-06-09 Zig master builds now with FreeBSD support
  • 2025-06-07 Finding rust dependencies in Makefile.crates
  • 2025-06-05 Ripgrep or ripgrep-all
  • 2025-06-02 Ripgrep a nice Rust utility for ports spelunking
  • 2025-05-31 Get started with gpui on FreeBSD
  • 2025-05-29 Query freshports with Deno
  • 2025-05-27 Trying out Defuddle an npm tool via Deno
  • 2025-05-25 Deno for FreeBSD
  • 2025-05-23 A new beginning

2025-07-28 The rustup question

In previous posts, I have highlighted specific projects in Rust that are known to work (and be packaged) under FreeBSD. I am going to use this post as a transition point for future posts to a more general rambling about BSD (still reserve the right to highlight Rust things if something catches my attention). As a general rule of thumb, a pure Rust project has a much better chance of being able to compile and work under FreeBSD without modification than one that uses external C libraries or such. One example would be the tauri framework which embeds the 'native' web browser engine (which is most likely webkit for Linux and FreeBSD). While the Rust specific bits for tauri would probably work fine the webkit portion is most likely not ready for any targets outside of the win-mac-lin triumvirate.

However, the other question that I think comes up when integrating Rust on FreeBSD is how do you approach handling Rust as just another dependency itself? If you're doing active development (or maintenance) on tools that are written in Rust, I have found it is easier to use rustup to manage handling rust itself. If you're only planning to use a tool without any plans to tweak it then you are probably better off just seeing if the tool is available as a FreeBSD port / package and installing it from there.

The reasons (that I am aware of) for using rustup to manage a rust installation even when it is available as a package in FreeBSD are the following:

  • Use a more recent Rust compiler than what is packaged in pkg

  • Able to switch versions of Rust easily

  • Able to add other rustup managed components easily (ex. wasm target)

  • Easier to follow documented methods for working with Rust tools

There are probably more that I am not listing however the first item, which is really just a specialized case of item two, has been a gotcha that I have hit multiple times. I try a typical pattern of

$ git clone <some_rust_repo>
$ cd <some_crust_repo>
$ cargo build  

and then promptly run into the screenful of compile errors only to discover that a particular version of the Rust compiler fixes this as said project wasn't specific on which version of Rust it needed. While it is possible to specify rust version in cargo, it's also possible that the developers have specified otherwise such as in their README or perhaps in a BUILDING document of some sort.

One thing this post touches on that I will elide (possible future post) is how the newer generation of programming language specific package managers create a new type of strain (am I overlooked?) for operating system package managers.

PREVRANDOMNEXT