Am Montag, den 14.06.2021, 16:29 +0200 schrieb Pjotr Prins: > On Tue, Jun 08, 2021 at 03:11:31PM +0200, Ludovic Courtès wrote: > > (I’m late to the party…) > > Never late :) > > > > I found a cargo -> ninja converter. It is that kind of idea. Guix > > > would use ninja with rustc instead of cargo. A stripped down > > > cargo > > > could potentially work too - but cargo is a complex beast. > > > > In a way, aren’t importers addressing this use case? > > Importers and build-systems, even guix.scm, don't really create a > rapid and dynamic builder for developers to use when developing > software. At the same time the builders, such as cargo, are heavy, > bloated and misguided. And hard to embed in GNU Guix for multiple > reasons. > > There is a missing link in my opinion. Though it is not a > Guix problem (I agree). This is really something that's true rather for cargo than for most other builders, though. gnu-build-system, meson-build-system etc. are – in my opinion – appropriately sized and a hypothetical cargo-ninja- build-system could just reuse most of meson-build-system but creating the ninja files from cargo rather than meson (i.e. swapping the configure phase).
As for "rapid development", `guix environment` provides the things you need in an environment (heh), that is simple to set up. The missing link when that is already given is to set up the build system that you'd use anyway. I think most modern tools have a --generate-me-some- generic-hello-world-template, whereas for the GNU Build System you simply copy amhello. > > In the end, they let everyone develop a package manager/build > > system > > that suits their needs, while still allowing us to have our cake. > > If you strip out dependency management and cross-platform compiling > there is not much left to do for cmake, autotools, cargo etc. > Everything Guix is good at. Ninja resolves the build graph, you only > need something to generate the build graph for source files. A > mini-Guix of sorts for source files. Eelco, at the time, wrote Maak - > a builder that would work on NixOS. He wrote it in Haskell, but it is > similar thinking. There never was that much to do for a build system. All they're supposed to do is to simplify a sequence of compiler and linker calls, so that you can write `make all' instead of having to type out 500 invocations of GCC. They were never meant to be package managers and those who think they are will be doomed to reinvent the wheel over and over again. They instead provide an interface to package managers, that interface being e.g. the locations in which they will generally look for certain headers (though reasonable build systems and package managers use pkg-config to solve this issue as well). > https://en.wikipedia.org/wiki/Maak > > Ninja fits the bill - but it is something that needs to be generated. > > Minimalism and simplicity is what I want. I hate it when software > starts thinking for me ;). > > https://github.com/rust-lang/cargo/issues/6584 > > We need to create another builder that replaces cargo - or maybe just > simplifies cargo. I am not programming in Rust or Racket, right now, > but when I do (again), I'll try to generate ninja files to define a > build as a starting point in a simple way. One thing we can do with > Guix is create a parallel build system. An alt-verse for builders ;) How build systems proliferate Situation: There are 14 competing build systems Developer: 14?! Ridiculous! We need to develop one universal standard, that covers everyone's use cases. Developer with a ponytail: Yeah! Soon: There are 15 competing build systems Guix as a build system, with or without GWL, is fine as long as it's just fun and games, but it comes with the serious downside of not being compatible with any other distro out there. Perhaps that works out for those, who pray towards our lord and saviour Flatpak, but if you want to be able to ship to traditional distros through normal channels, you will need a reasonable build system like make or ninja and perhaps something that generates you the nitty gritty stuff like Autotools, Meson, etc. What we need in order to make packages written in Rust less of a PITA is more widespread usage of generic build systems like make or meson. We won't get there with cargo cult programming. On a somewhat related note, I find it amusing, that Rust folk dread the usage of Rust without cargo, as if the Rust standard library on its own was somehow worthless or something :P Regards, Leo
