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

[Pjotr Prins <pjotr.public12@thebird.nl>]

On Tue, Jun 01, 2021 at 08:24:51AM +0200, Leo Prikler wrote:
> > 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.

Industry appears to go the other way. There are several initiatives to
speed up Rust through caching and storing compiled items in the
cloud(?!).

> 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

Particularly where it comes to cross-platform building
and things like CUDA and webassembly. I don't think we should
try and duplicate all of cargo though. 

> I don't think this would be simpler to Guix, you'd just create even
> more packages, that actually aren't usable.

We'd have to see. Adriano made a great point about composability.

Truth is *I* have been annoyed by build systems for ages - one of the
first attractions of Guix was successfully getting rid of Ruby bundler
when we wrote the Ruby build system. Guix goes a long way towards
simplifying the actual requirements for a build system because it
handles dependencies and 'flavours'. So, we can come up with something
simple. When I was coding in D I had similar thoughts - I managed to
avoid the D build system completely. Now I want to achieve the same
with Rust!

> that cargo does.  It doesn't shake the ginormous dependency trees for
> example.

No. That issue sits partly with developers though Cargo and npm make
it far too easy to pull in 500 dependencies ;). I always remember Joe
Armstrong, who said that part of the longevity of Erlang is that it had
virtually no dependencies. Long running projects do well to think
about that statement. There is also the security angle...

Simplifying packages is not the remit of GNU Guix. But sexp-pack
(or should we name it sixp-pack to avoid criticism?) can simplify by
throwing out needless dependencies. I don't buy it when an 'hello
world' program requires 100+ dependencies. And I have already seen
that with Rust. If we manage to scale down and influence developers -
we may influence the industry. Who knows :)

> 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

The cargo->ninja converter was just an example. I kinda like ninja
because it is really simple minded and minimalistic. We could come up
with a scheme->ninja generator (I don't like cmake or meson so much).
ninja comes into play when you want to do incremental builds - which
is important for developers. Another reason to introduce a new layer.

> currently looking towards Rome to perhaps simplify node-build-system or
> erect a new build system next to it.

I really respect the accumulated knowledge we have in the Guix
community for build systems. That is one reason for bringing it up on
the mailing list rather than trying to just hack something.

> 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.

The real problem is that all(?) sources need to be visible, similar to
.h include files in C, right? Rust code inlining optimizations too, so
it needs the source view. To me the solution sounds to include the
necessary source code with the deployed package, or at least have a
-dev version for builds.  Efraim suggest looking at what Debian does.
They somehow include the full source space.

> > 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

We can still have both ;). It is true that sixp-pack would be an
alt-verse, unless we ascertain cargo picks up deployed -dev packages
properly. 

Another option is to hack and partly disable cargo - so it only
builds. I know we are resistant to changing upstream packagers, but if
it is the easier way we might want to consider it.

Pj.