every worthwhile link on how to implement your own squeeblerizer is dead and approximately 40% archived
cross-posted from: https://lemmy.blahaj.zone/post/20883609
You're viewing a single thread.
- libsnorble-2-dev, a C library that the author only distributes as source code and therefore must be compiled from source using CMake
Of the available options, this is easily the best since I can use my own compilation flags to tune the library for my specific target architecture/CPU which can possibly change as the deployment profile for the business case evolves. Assuming it's OSS, I can also fork and adjust the library itself for said "mission-critical" use case.
Also, the Google product being deprecated since '17 is too real 😅...
Yup. If source is not available I’m not using it if I have any choice in the matter. Binary distribution is nice, but I’d rather have source.
Plus I’m sure some kind soul has created a build pipeline that autogenerates binaries from the source. I can always either use that or clone and customize it. It’s a natural separation—as a dev I’d like my responsibility to end at “I merged working code to trunk”.
And here I would argue that the Rust library is strictly better, specifically because it will come with an automated or precompiled build of the C library. Compiling C is such a pain.
i just knew the fanatical rust fans would just have to push Sprongloxide. Broken records!
I personally love Rust, but since I'm already familiar with C/CMake, I just don't think I need to "re-invent the wheel". In this case, using the Rust wrapper option is more like "trying to put a winter tire around an all-weather tire".
Also, on Gentoo Linux, there will be an ebuild that integrates all of the cmake options into the rest of the packaging system and manage the dependencies
Any similar system for Kubuntu 24.04 LTS noobs/normies like me? I don't know what "ebuild" is, but it sounds cool (of course, I could look it up, but I thought I'd just ask).
I'm not a dev-ops dude, but for work, I develop parametric CAD solutions and generative DNNs for CAD. Lots of linear algebra and Pytorch on the GNU-Linux side; lots of Grasshopper for Rhino8 on the Win11 side. Hence, I use Docker to separate my experimental build environments from my production ones.
I've been kinda maintaining my shit "by hand", so to speak, for years now, and I think I'm ready for some automation in that regard.
An ebuild is a definition - a recipe, if you will - of how a package is built from some source by portage, a Gentoo package manager.
Very few things are trully impossible in linux land, but having multiple package managers on a single system is just asking for trouble.
You could try setting up a gentoo prefix and get the benefits of portage that way, but I've not beem able to accomplish that the single time that I tried.
Ah okay, specific for Gentoo, I see. Thus, since I'm in *buntu land (--minimal-install, so no snap fuckery), it's better to just set up an apt repo and use my build containers to push to that.
Very few things are trully impossible in linux land, but having multiple package managers on a single system is just asking for trouble.
Nix/Guix are specifically designed to not interfere with the rest of your system.
You can try out Nix. It can be installed right there on your Kubuntu box, without any conflicts with apt or other package managers.
It's somewhat similar to portage with its ebuilds in that it's source-first and allows you to set up complex dependency trees and configure every package in them. In your case it would allow you to avoid manual rebuilds and just build&install all your custom software with one command from one directory containing some .nix files that describe how to fetch, configure and compile every package. (Actually, for your dependencies those files are likely to be in nixpkgs already - you can check at https://search.nixos.org/packages. In that case, you don't have to write any packaging instructions or even build everything, as Nix will intelligently download the binary versions which are helpfully provided by the Nix community).
It's quite different from most other package managers/build systems, though, being much "simpler" (it can be described as lambda calculus on files with syntax sugar) but much "harder" (the learning curve is actually a learning wall with the first section requiring mountain climbing experience and covered in barbed wire). If you've been maintaining builds for multiple packages by hand for years, though, it shouldn't be too bad.