From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id wHniH7LgtWBOFAEAgWs5BA (envelope-from ) for ; Tue, 01 Jun 2021 09:24:34 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id wK0hG7LgtWBIZAAAB5/wlQ (envelope-from ) for ; Tue, 01 Jun 2021 07:24:34 +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 15D7613340 for ; Tue, 1 Jun 2021 09:24:34 +0200 (CEST) Received: from localhost ([::1]:47958 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lnylM-0001Bi-OK for larch@yhetil.org; Tue, 01 Jun 2021 03:24:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42924) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lnykI-0001BZ-1n for guix-devel@gnu.org; Tue, 01 Jun 2021 03:23:26 -0400 Received: from mail.thebird.nl ([94.142.245.5]:57350) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lnykD-0002T3-Ba for guix-devel@gnu.org; Tue, 01 Jun 2021 03:23:25 -0400 Received: by mail.thebird.nl (Postfix, from userid 1000) id 134AC1053; Tue, 1 Jun 2021 09:23:18 +0200 (CEST) Date: Tue, 1 Jun 2021 09:23:18 +0200 From: Pjotr Prins To: Leo Prikler Subject: Re: Idea: a meta language for (language) build systems - npm, Racket, Rust cargo Message-ID: <20210601072318.etclsrwo7dcdizst@thebird.nl> References: <20210530083847.o5ej63obqnzpwnbd@thebird.nl> <20210531174748.mhaelcqwmo7degfc@thebird.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Received-SPF: pass client-ip=94.142.245.5; envelope-from=pjotr2021@thebird.nl; helo=mail.thebird.nl X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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=1622532274; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=LiKugH9O6dIj6RkF7anZbh8ZhoDpHk6tlRye9qU+msM=; b=VNCXIqPoM0H2dXr1XHQytUIa6CrqvtzynRs0IvMZBkkk3flVziYy6zcZtVJK4CMk/yrUlg iTSR0HjnWkgsYXihasK1DONw1u2WEAS/Lh8FmRMp7vFmKkAerUwITNwkvzEc5N1kPO7F8B K1wyp6v/jGRNp6dxc8dJr5PvDrS0yaOIe3UGJg7Kb0tdulrGOX/MbfYoz254KmbLUJEXFs f3RVlZc08f6dCbDhiBNxX106mJUMy2ixGVGefsgzngZe4LjXJErMzXgjJGtzqiGw8CAWp7 PJk8Da2BLAZpuzDra3zKKAZqljWdg0HStE18NbI0HbYB/hye3lIc6isu8P6QNw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1622532274; a=rsa-sha256; cv=none; b=azp725XbJCF4jkOXbKNRZCYWz/pRSLK47LxCKF3H4vt+YbPSm6ngQ5lpXEqb+7OCPbeO84 +ej2DitDyYfvv5Dm6OV+eCk8RyWx4ltaE74BNhuDNFZzgTnQV4CtS9+afHUqWnl73IRqZh z/JV5qfPbeAXhI4bqD4+D+7xwplyxmtSfBTyFaQFKK4GUvSUllOrwUeH5KlGoTQUN7JnBJ riIglz4bm3L30eP+Uj1Ye1oljH+Atlo6MLFClm74ygF3ycp/ppx/7WEAkmR+bCyQVriYWf D2kuyf1hhhxF6oKtOeTnnuNXB6E4O16qNTaFPgGfkOplhxE/1BtsWzV7XMDIrw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=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: -2.43 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=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: 15D7613340 X-Spam-Score: -2.43 X-Migadu-Scanner: scn0.migadu.com X-TUID: 0XlYSApVspN+ 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.