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

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

Am Montag, den 31.05.2021, 19:47 +0200 schrieb Pjotr Prins:
> On Sun, May 30, 2021 at 09:17:20PM +0200, Konrad Hinsen wrote:
> > How about pushing all the other package manager towards producing
> > sexp-packs, and helping them to get there?
> 
> I have a feeling they won't be that interested ;).
I do think some of them are interested, but you're right in that the
industry as a whole is not.

> My thoughts are that every software package simply consists of files
> that need to be compiled (if not interpreted) and be copied in place.
That is the case, but surely you aren't suggesting to implement all
build systems in terms of copy-build-system, right? :P

> As Guix takes care of the first and the last - the issue centers
> around building. The idea is to dress down these language specific
> builders, such as cargo, so you don't have all the included
> complexity. 
The thing with complex systems is that you will still have complexity
no matter how you look at them and cargo is such a system.  The only
way to not see that complexity is to ignore it because your build
succeeds, and I'm sure Rust, npm, etc. users (read: victims) are
physically trained to clear their mind from such heathen thought.

> A sexp-pack would represent the most simple build instructions to
> build a package on its own. Now, of course the current guix-builders
> solve that too. But, what I am proposing is to split out the actual
> build step into a package definition, so as to present something
> simpler to Guix.
I don't think this would be simpler to Guix, you'd just create even
more packages, that actually aren't usable.

> 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.
The problem with rust+cargo is not just that cargo isn't make or ninja
(although that is certainly a part of it), it is also that any
make/ninja port would have to somehow take care of all the other things
that cargo does.  It doesn't shake the ginormous dependency trees for
example.

This is not to say, that rustc+ninja is not worth pursuing.  If the
output of rustc+ninja had some nice property, e.g. it was a shared
library, that could be reused, we might still want to rewrite rust-
build-system in terms of it.  In a similar manner, Guix people are
currently looking towards Rome to perhaps simplify node-build-system or
erect a new build system next to it.

Small rant w.r.t. #:skip-build?, this flag is a hack and everyone
involved knows it and we ought to find a way to actually build rust
crates in a manner that doesn't require complete source closure for the
next rust-thingy to use it.

> A simplified build step would make it easier to troubleshoot these
> packages.
I think I'd personally rather deal with the output of make or ninja
over that provided by rust/cargo 9 times out of 10 if that is what
you're going for, but different strokes for different folks.  We don't
want to alienate all the people actually using Rust on Guix by taking
away their favourite error message :P

Regards,
Leo