Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo

[Leo Prikler <leo.prikler@student.tugraz.at>]

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