From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 6BxuKP7rtWAHLwEAgWs5BA (envelope-from ) for ; Tue, 01 Jun 2021 10:12:46 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id ABe2I/7rtWCmUgAA1q6Kng (envelope-from ) for ; Tue, 01 Jun 2021 08:12:46 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 135B413F0B for ; Tue, 1 Jun 2021 10:12:46 +0200 (CEST) Received: from localhost ([::1]:58410 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lnzW1-0003bK-3Q for larch@yhetil.org; Tue, 01 Jun 2021 04:12:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53326) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lnzVr-0003b6-E6 for guix-devel@gnu.org; Tue, 01 Jun 2021 04:12:35 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:2635) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lnzVn-0001bb-DD for guix-devel@gnu.org; Tue, 01 Jun 2021 04:12:34 -0400 Received: from [10.0.0.4] (62-116-34-49.adsl.highway.telekom.at [62.116.34.49]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4FvPyw6yTyz3wFM; Tue, 1 Jun 2021 10:12:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1622535145; bh=/oWam+7mtE18Fc+6c2fxutJXvemka5cxkl3CLEzrtsg=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=GNVhkPUKxHaKPjJEykQts5rZFWg/jWjJxzUiqsXJCLhSMRWgjBvo7Vzfq3JJRHKbZ 5HD9FcMCziuq/UgmHdEawV7uPWvekc/SLaV0rpDCGDbp/4kkKDN8hxCztvnegWYyeS 9CET2gSKbYjxcajnlUJRylql5XIOIxa7veosQ8sI= Message-ID: <6752eeda3dadc51fae71b83d460e7237f01da391.camel@student.tugraz.at> Subject: Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo From: Leo Prikler To: Pjotr Prins Date: Tue, 01 Jun 2021 10:12:02 +0200 In-Reply-To: <20210601072318.etclsrwo7dcdizst@thebird.nl> References: <20210530083847.o5ej63obqnzpwnbd@thebird.nl> <20210531174748.mhaelcqwmo7degfc@thebird.nl> <20210601072318.etclsrwo7dcdizst@thebird.nl> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TUG-Backscatter-control: bt4lQm5Tva3SBgCuw0EnZw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 Received-SPF: pass client-ip=129.27.2.202; envelope-from=leo.prikler@student.tugraz.at; helo=mailrelay.tugraz.at X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1622535166; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=/oWam+7mtE18Fc+6c2fxutJXvemka5cxkl3CLEzrtsg=; b=doku8MPIuMdbg+BupxGxsBE6Q4h1j5nFtZe3Sl705dqX6YNCGfDnnNlzaTKitiyOrxuuym gXS3OGx9laD5PTDR4eWwoCgD/eow0gguT3t9jGiJ5vtMVM5bqgGm72KQVpJpK8bBnFBhn2 g/xcKj8xAApvcdGQba5FwenjyWJesk3yrasouM1seHBfrprN5bCjzWzCdYK7eY4uq/tRnP n9cXRn1+oM2btbpe4mtXEnYfN/gI5NLE8zyEURUooNVKKYkocLYVvM0vIjdxDV4QU3Ddfx dtATgZgni1+vXJ5V879quygAzSb3SIALeOjCdqd2C19KMRVCIrONGb6E2L2pPg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1622535166; a=rsa-sha256; cv=none; b=QR5fy/+waiGgFVBMOh3ZagkFJDcKJrfsr0jvUIU2y5+FVor5QRl5CjfAb2dEBtDT/7IXC9 79r8cc6LV/zVveM0mVa/GWEjiLXusU8zCjCrMQ6PasWtNmtK1RvkV42cV/+JonmIkchAlR spQpcT8a9PzPAUGID+ekzr9Pli2ubVWHsf/zD7FZOBavfXm774/CSVpPlzkxA+1ns1NE+Q UQsbzggwQQxAox2Wu+SOmOv9dZoum14OoUtZmAZcUj4Mtrjp3Ea6XgxKB1xikixQQy6ohh zahrQOzPvHvhDzF+X7yCjXmcGbP82TUEOdteGEFOu17uIX3RCVb+cMqjbycVNg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=GNVhkPUK; dmarc=fail reason="SPF not aligned (relaxed)" header.from=student.tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -1.33 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=GNVhkPUK; dmarc=fail reason="SPF not aligned (relaxed)" header.from=student.tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 135B413F0B X-Spam-Score: -1.33 X-Migadu-Scanner: scn1.migadu.com X-TUID: zV7Lk35s04FZ 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 elsewhere. > > 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 Elixir? > 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. Regards, Leo