RGBCube/Site
1
Fork 0
mirror of https://github.com/RGBCube/Site synced 2025-07-30 12:37:50 +00:00
Code Issues Activity Actions

dump(build-systems.no-gnulib): move to blog

Browse source
This commit is contained in:
RGBCube 2025-07-20 00:08:56 +03:00
parent a851f5b317
commit 7a7eb76262
Signed by: RGBCube
SSH key fingerprint: SHA256:CzqbPcfwt+GxFYNnFVCqoN5Itn4YFrshg1TrnACpA5M
1 changed files with 8 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

16
site/dump/build-systems/no-gnulib.md → site/blog/2025-07-20-no-gnulib.md
View file

@ -1,7 +1,6 @@
---
title: Say NO to Gnulib
description: ...and Debian.
date: 2025-07-19
---
If you are a GNU maintainer and are not willing to be critizied by people sick
@ -38,7 +37,7 @@ of Gnulib.
I do however trust the average distro (not Debian, they are lower than average
and suck at packaging [(Yes, really.)](#debian-sucks-at-packaging) to build
Uutils tools & any other Rust tool correctly, because it is pretty relatively
straightforward compared to hundreds of thounsands of lines of ancient m4. Much
straightforward compared to hundreds of thousands of lines of ancient m4. Much
easier to audit too & it doesn't misbehave or segfault.
I hope Uutils coreutils & Uutils findutils and so on achieves near perfect
@ -85,11 +84,12 @@ and you should not be anyway.
The way you should package any programming language that has a widely used and
generally well-defined and static build system is to generate (unlisted) package
definitions from packages using a script or tool (such as
`cargo metdata -> parse json -> puke out package manifests`), and only add extra
configuration to packages that depend on anything external (such as a C library,
or CMake, or perl, or Go for some godforsaken reason (Why, `aws-lc-sys`, why?)).
`cargo metadata -> parse json -> puke out package manifests`), and only add
extra configuration to packages that depend on anything external (such as a C
library, or CMake, or perl, or Go for some godforsaken reason (Why,
`aws-lc-sys`, why?)).
It's also not hard to use a dependency solver algoritm to try and deduplicate
It's also not hard to use a dependency solver algorithm to try and deduplicate
all crates required in the whole package repository using a pre-made library,
such as [`lib.rs/pubgrub`](https://lib.rs/crates/pubgrub). You can have the best
of all worlds.
@ -133,12 +133,12 @@ derivations (build units, but in a fancy Nix / Functional Software Deployment
Model way), these generated definitions won't pollute search or interfere with
users. It's just a plus in almost every way imagineable.[^A negative would be
the sandbox creation overhead of `nix-daemon`, but that shouldn't be significant
most of Rust builds from scratch, and for those that are, the already-cached
for most of Rust builds from scratch, and for those that are, the already-cached
crates will mitigate the losses pretty easily.]
<blockquote>
You can actaully use this right now with
You can actually use this right now with
[`cargo2nix`](https://github.com/cargo2nix/cargo2nix) or
[`crate2nix`](https://github.com/nix-community/crate2nix), though expect some
headaches. (I recently spent a few hours getting `crate2nix` to work on a huge