From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id qCPxHwRQc2fdGAEAe85BDQ:P1 (envelope-from ) for ; Tue, 31 Dec 2024 01:59:32 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id qCPxHwRQc2fdGAEAe85BDQ (envelope-from ) for ; Tue, 31 Dec 2024 02:59:32 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=disroot.org header.s=mail header.b=KwyEn+J2; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=reject) header.from=disroot.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1735610372; 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:dkim-signature; bh=3yOidR4NPFFKvOdEteQ8rw4v3z37ewJMuzPaf/JYDXQ=; b=b3B0h5ACIjM27hJUdV6ziD7/DzbvxzPdbRw/XlZ380Xzpp1UoISV1ZIQiXn6vJupy5sucI PwUjhzcloxKIZBOUKzkh1dGUfF6HFOEX8laxWFQuzNHQ1F7LzrcaRexNsCumyjseuAEDmY bydH25eWT5Ynx5uCEHeOlaG0sM64/kS71zDe1gNhn1R8O7fmrcuXDvNw7ZyQSP2+UUJZrJ XQNXJAKi8kyAfAo52TqBARoiUliF9k/T+GrLevd7o9FyYcKsNyH46oTXuUqfpr8M8gXfa0 /zdZ3WQZCbW1h9WOVNoN5jfhdjPyyKb9+sdx242gwF9LJWPP8kpoVKBkEI1dRQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=disroot.org header.s=mail header.b=KwyEn+J2; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=reject) header.from=disroot.org ARC-Seal: i=1; s=key1; d=yhetil.org; t=1735610372; a=rsa-sha256; cv=none; b=d9Z8OtStgKh8igj6kOKIC8r+m097dTbQ6+6NEG1gbIhMJR66q6hgjtMxOSG1CXbR9EA9rS VaYKf8L0tJLtfMqVzPIx1yJ+UkwpqECzlgsgqeyPW/h4FX+Zn+DILIITZ9A9wJntXr/7l3 gPmpArvL06VGOCoLDf87YmStCA1773nSMwg4/idd0jLjQpRdLv7UfECxOhwzi8/wB5fpTD zFZWkHPvTr0Knjaa9NI2yU8vqV/J5/2Who2Q2GCyghB1DM9pOoproRJNnIZ7SapayXoh9A 92WnpdTwQJR1JMzIc9rKZs/qeTo9deqUQZfsmX2YSeSsUVBxLVYGa+xvKzNg0w== 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 1DD3075C0 for ; Tue, 31 Dec 2024 02:59:31 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSRX7-0005Qf-Sg; Mon, 30 Dec 2024 20:58:58 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tSRX5-0005QU-Ec for guix-devel@gnu.org; Mon, 30 Dec 2024 20:58:55 -0500 Received: from layka.disroot.org ([178.21.23.139]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tSRX2-00040S-Ns for guix-devel@gnu.org; Mon, 30 Dec 2024 20:58:55 -0500 Received: from mail01.disroot.lan (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 35D82259F2; Tue, 31 Dec 2024 02:58:49 +0100 (CET) X-Virus-Scanned: SPAM Filter at disroot.org Received: from layka.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavis, port 10024) with ESMTP id MUV373hbhV95; Tue, 31 Dec 2024 02:58:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1735610324; bh=5GW6uhHz/xFSV7Z5yiSYNr5y/nRrmUySdH2tGCzB+Xo=; h=Date:Subject:To:References:From:Cc:In-Reply-To; b=KwyEn+J2J14wCh/xqS9sc1wlWdIHsasOojwWodQ3aaHdUyx183aPnyLg3f4IQWJK5 iYMnM69qocCCkNWJNEwIRBHYX74DfxhjnggEJLAS8GkHvFPUuK7xpDVxGwYom8PJaV avmQLgSdGqUEx2dyJd+KyFM+ExHRZ7V8lhrDBmL0G7eK9DWpCYrCOAalzd8wIm4tHR kxGP59UqT4B4JVoKD+mh54zYwuPNlsPz/f/Ye4rj9PCNuG4WvLNGHBU1dAJbXorTh2 l0uZyBTuHWjf+nkfagNcu+WHaNG6w9kDNGdVPlYK5og7u5T/E1QDMT8xHHsjWKtwO5 zG6urgFdrBEgw== Content-Type: multipart/alternative; boundary="------------Wpvkj9bXhidit60YJaf1J5Sh" Message-ID: <0139862d-01c9-450e-8f4e-f78e653986c5@disroot.org> Date: Tue, 31 Dec 2024 03:58:43 +0200 MIME-Version: 1.0 Subject: Re: On a Guile-based Build-Tool complimenting Guix To: Divya Ranjan References: <87wmfvo2je.fsf@subvertising.org> <86F8BAD1-1388-4B61-AF2C-5D0E510DB8C0@subvertising.org> Content-Language: en-US From: Fi Cc: guix-devel@gnu.org In-Reply-To: <86F8BAD1-1388-4B61-AF2C-5D0E510DB8C0@subvertising.org> Received-SPF: pass client-ip=178.21.23.139; envelope-from=lapearldot@disroot.org; helo=layka.disroot.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=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.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Queue-Id: 1DD3075C0 X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -4.19 X-Spam-Score: -4.19 X-TUID: 9Nk0CAG9lGK6 This is a multi-part message in MIME format. --------------Wpvkj9bXhidit60YJaf1J5Sh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello! For what its worth, I mentioned it only in the capacity of the opportunit= y to share work with meson. So in answer, I meant a guile interface to meson, with the backend of mes= on remaining the same I develop a lot with the gnome ecosystem and the meson project makes acco= mmodations for that although I am sure there are other nice options. On 28. 12. 24 3:51, Divya Ranjan wrote: > Hello Fi, > > Would you prefer a guile interface to meson, or a meson replacement in = Guile? > > Regards, > > > On 27 December 2024 00:41:33 GMT, Fi wrote: > > I was thinking this the other day!, was wondering about how useful = a guile interface to meson would be. On 19. 12. 24 22:12, Divya Ranjan wr= ote: > > Hello Guix, The other day, after being frustrated of build syst= ems (auto-tools, meson, maven etc.), I wondered why doesn=E2=80=99t Guix = which has such powerful tools within it (`guix build`, `guix pack` etc.) = also not have a purely Guile-based build tool? After all, our goal is to = make deployment, and building both more declarative and away from the all= -too-familiar =E2=80=9Cdependency hell=E2=80=9D. I am not exactly sure ho= w I want to go with this, but I want to extend (if needed) the capabiliti= es of Guix, to allow the developer of a package to use it also to build t= he package effectively replacing existing build tools. Since we already h= ave build-system, instead of executing make (or whatever other tool) comm= ands from it, we could modify it to itself have all those things that a M= akefile would have. The developer would use Guile to declare their build = config, I am again not sure what this might exactly look like, but can=E2= =80=99t we have it such that we provide the developer with some tools to > _declare_ a custom and package-specific build-system in Guile (= just like our familiar gnu-build-system), but this is purely in Guile and= executes whatever commands, path declarations and other interactions (su= ch as calling gcc) directly from Guile and not by just calling `make`. I = haven=E2=80=99t thought through this clearly, but even if this doesn=E2=80= =99t work, the main idea I=E2=80=99d like to propose is to fully replace = existing build-tools by making a new Guile build tool to work alongside G= uix. Ideally, once the developer has a build config ready, one can just w= rap it up with a package definition in Guile, just like the ones we creat= e to package something upstream. This package definition can then be used= in `guix build -f package.scm` to result in a fully transactional buildi= ng process that focuses not on getting out of dependency hell, but just d= eclaring your config right. And all of this without having to learn yet a= nother build tool that might disappear, and of course, without > leaving the comfortable world of Lisp (Scheme). I was indicated= by others that such an idea has previously been conceievd among Guix dev= elopers themselves, namely as a GSoC proposal[0]. I couldn=E2=80=99t find= if that has progressed towards anything, nor could find anything in the = mailing list. I did see Pjotr volunteering to mentor for it, I=E2=80=99ve= CC-ed them to see if they=E2=80=99re still interested in such a project.= Meanwhile, I=E2=80=99d like input from other Guix core developers on wha= t they think of this, and if they could provide me with some leads on whe= re to go with this. [0]: https://libreplanet.org/wiki/Group:Guix/GSoC-202= 4 Regards,=20 > > Divya Ranjan, Mathematics, Philosophy and Libre Software --------------Wpvkj9bXhidit60YJaf1J5Sh Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hello!
For what its worth, I mentioned it only in the capacity of the opportunity to share work with meson.
So in answer, I meant a guile interface to meson, with the backend of meson remaining the same
I develop a lot with the gnome ecosystem and the meson project makes accommodations for that although I am sure there are other nice options.

On 28. 12. 24 3:51, Divya Ranjan wrote:
Hello Fi,

Would you prefer a guile interface to meson, or a meson replacement in Guile?

Regards,


On 27 December 2024 00:41:33 GMT, Fi <lapearldot@disroot.org> wrote:
I was thinking this the other day!, was wondering about how useful a guile interface to meson would be.

On 19. 12. 24 22:12, Divya Ranjan wrote:

 Hello Guix,

 The other day, after being frustrated of build systems (auto-tools, meson, maven etc.), I wondered why doesn’t Guix which has such powerful tools within it (`guix build`, `guix pack` etc.) also not have a purely Guile-based build tool? After all, our goal is to make deployment, and building both more declarative and away from the all-too-familiar “dependency hell”.

 I am not exactly sure how I want to go with this, but I want to extend (if needed) the capabilities of Guix, to allow the developer of a package to use it also to build the package effectively replacing existing build tools. Since we already have build-system, instead of executing make (or whatever other tool) commands from it, we could modify it to itself have all those things that a Makefile would have.

 The developer would use Guile to declare their build config, I am again not sure what this might exactly look like, but can’t we have it such that we provide the developer with some tools to _declare_ a custom and package-specific build-system in Guile (just like our familiar gnu-build-system), but this is purely in Guile and executes whatever commands, path declarations and other interactions (such as calling gcc) directly from Guile and not by just calling `make`. I haven’t thought through this clearly, but even if this doesn’t work, the main idea I’d like to propose is to fully replace existing build-tools by making a new Guile build tool to work alongside Guix.

 Ideally, once the developer has a build config ready, one can just wrap it up with a package definition in Guile, just like the ones we create to package something upstream. This package definition can then be used in `guix build -f package.scm` to result in a fully transactional building process that focuses not on getting out of dependency hell, but just declaring your config right. And all of this without having to learn yet another build tool that might disappear, and of course, without leaving the comfortable world of Lisp (Scheme).

 I was indicated by others that such an idea has previously been conceievd among Guix developers themselves, namely as a GSoC proposal[0]. I couldn’t find if that has progressed towards anything, nor could find anything in the mailing list. I did see Pjotr volunteering to mentor for it, I’ve CC-ed them to see if they’re still interested in such a project. Meanwhile, I’d like input from other Guix core developers on what they think of this, and if they could provide me with some leads on where to go with this.


 [0]: https://libreplanet.org/wiki/Group:Guix/GSoC-2024

 Regards,
Divya Ranjan, Mathematics, Philosophy and Libre Software
--------------Wpvkj9bXhidit60YJaf1J5Sh--