[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Leo Prikler
Subject: Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo
Date: Tue, 01 Jun 2021 10:12:02 +0200
User-agent: Evolution 3.34.2

Am Dienstag, den 01.06.2021, 09:23 +0200 schrieb Pjotr Prins:
> 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(?!).
We can go even faster: Build all rust stuff itself in the cloud and
never locally.  That way, we can also ensure, that there's no pesky
people trying to inject other packages by building offline.

> > 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. 
Neither do I.

> > 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 is a noble goal, but I'm not convinced your proposed solution does
that.  It rather appears to me as though it pushes the actual problem

> > 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...
The issue is very much in the system as it encourages and often
requires such behaviour.  Basically, language package managers don't
know how to be good package managers.  I see the same problem with the
proposed package management solutions towards Erlang.  Ever heard about

> 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 :)
How would your macho build system be any different from Guix in that
regard, though?  Guix already has all the notions of inputs, outputs,
etc. that you need.  Especially with Rust, which already has packages
that DON'T DO ANYTHING DURING BUILD, I struggle to see how macho build
system would be a useful abstraction.

Now you might ask yourself "why do I even need to package Rust library
#2147483647, can't I just stuff everything into a computed origin and
yolo my way out?", but that's exactly the kind of thing we DON'T want
to do.

> > 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.
GWL also has incremental builds.  What's your point?

> > 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.
Assuming, that master does not yet copy all sources to output, a patch
that does that already sits in the MLs.  No, it does not solve the
issues I've pointed out, particularly not #:skip-build?

> > > 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. 
We don't do -dev packages.  At best, we might want to have outputs for
static libs or binaries or stuff like that.  No -dev packages.

> 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.
We don't need to hack cargo so that it only builds, we have already
configured it, so that inside a build environment anything that would
result in it not building but rather doing something else instead
conjures the error message Rust devs believe to be the most appropriate
for it not being able to do that.  I don't think such a change is
meaningful outside of `guix build'.  We might still need to do it to
comply with the FSDG, but that's a different issue.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]