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.
