From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id sGYxNczCY2DxXQEAgWs5BA (envelope-from ) for ; Wed, 31 Mar 2021 02:31:08 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id gCg3L8zCY2DyewAAbx9fmQ (envelope-from ) for ; Wed, 31 Mar 2021 00:31:08 +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 36AD09FCF for ; Wed, 31 Mar 2021 02:31:08 +0200 (CEST) Received: from localhost ([::1]:44746 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lROlH-00064f-0s for larch@yhetil.org; Tue, 30 Mar 2021 20:31:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35196) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lROkR-00063Y-Id for guix-devel@gnu.org; Tue, 30 Mar 2021 20:30:19 -0400 Received: from world.peace.net ([64.112.178.59]:39342) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lROkM-0005bA-EP for guix-devel@gnu.org; Tue, 30 Mar 2021 20:30:15 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lROkJ-00084Z-Qp; Tue, 30 Mar 2021 20:30:07 -0400 From: Mark H Weaver To: Julien Lepiller , guix-devel@gnu.org, Charles Direg Subject: Re: Question about compile packages In-Reply-To: <97998BD7-AAB3-49CD-8C4F-E4508B8FE32E@lepiller.eu> References: <97998BD7-AAB3-49CD-8C4F-E4508B8FE32E@lepiller.eu> Date: Tue, 30 Mar 2021 20:28:28 -0400 Message-ID: <87o8f017zs.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=64.112.178.59; envelope-from=mhw@netris.org; helo=world.peace.net 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_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: , 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=1617150668; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=XMtl3iQkpYHfDlY8jCRwEPbQTHEQoNQOtabt0qfHB50=; b=HCEMz0jqg55nINGvC9qv/bAUwG/JpW2Zz6lsRDzEEk+qbybIRk00JeKvMxMP+Wi+RIt0oo Tle+YntOX+oJrqY4fir1VPSGVjrZ0yyYXn73CuNRWkeFSlZaZUxdGYE1MgyToDIaJdv4EJ jET1iAyAp2tY2gnaWSv7+LYMjKt8V2JJYExuTsE6dj+aoz4I26wVd8YiTbbwH2WHF/UaHS 6rIYxmRuPOdJMwnfYk51A64yrWHolea652ATI2SstDzy5npwPMmOIXUEEH6czsq7+lA4xw sNE3hDFyhowbIbuD4HlU1EsS8gVwJBFeK9uAIvMj2fN9v0LgEt27t3IbNTB6rw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1617150668; a=rsa-sha256; cv=none; b=XZbVWy0550O2lLCvNLswnjLSqJJVeby2EeyXnpV8PtssxwRSkDUh7seI+NC0PAJqDKzeTN 97KxG/GaGHo0lFP8aqZ7P6uyC7RR4q8Ez4B7MNaGKRJ9qS3587jEcQtok5Uq6lBIC7uBrY I0va/ZaSPfhHUZLFy1Tv5wajB10TV29FwDOIGKroH1oUJN8hryuEL38RAK7UdMg4wA2vRP oxkcz8VfRF+oE8+P7VNyz/MlUaS59XnYFMQGso3oOFpadR6NqBOiE7g16QNqEiRJwywAWE igb0sooZYq31gZ5aF1HVXHM5sKdjJLbT0bwaImIZYjtoEP9jC1tgume56c31Xw== 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.42 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: 36AD09FCF X-Spam-Score: -2.42 X-Migadu-Scanner: scn0.migadu.com X-TUID: hko1ch/SQPPG Hi, Charles Direg asked: > How can I modify the flags that any program is compiled with within guix? That > is, I can allow in the gnu-build-system to modify it globally so that I can > add the build flags to any package, for example, add the flags -O2 > -march=native -mtune=native so global as I already mentioned, so that these > are added to each package at the time of compilation, this would not be > within the guix development environment, because what I want is that this > compilation is natively for my pc. Julien Lepiller replied: > Not sure about your first question. Maybe create your own fork and > regularly rebase it? Guix will not be very happy with that I think, > but it should work. I've been doing this all along, since the early days of Guix. No one seems to be unhappy with me about it, and I'm not sure why they would. I build everything locally, never use substitutes, and never use "guix pull". I always run guix via ./pre-inst-env from a git checkout of my personal private branch of Guix. I use a little script in ~/bin/guix that lets me simply type "guix ..." like everyone else: --8<---------------cut here---------------start------------->8--- #!/bin/sh source /var/guix/gcroots/per-user/mhw/environment-guix/etc/profile exec /home/mhw/guix/pre-inst-env guix "$@" --8<---------------cut here---------------end--------------->8--- I periodically rebase my private branch onto 'master', because I want to keep my private modifications in the form of a small number of patches, but if I didn't care about that, periodically merging master into my branch would also work. This approach gives *enormous* flexibility -- you can easily change just about any aspect of Guix, while still benefitting from our upstream work, and with nearly automatic merges thanks to git -- but there are some rough edges. One is that if you're not careful to keep a suitable build environment for building Guix, and your git checkout gets into a broken state, you can get stuck. Also, sometimes Guix adds additional build requirements, and so you can get into a state where you've updated your git checkout to a version with new requirements, but you cannot build those new requirements because your git checkout (from which you run guix) is not yet built. These problems are manageable, although it's slightly tedious. First, I'm very careful to always keep a GC root to a known working build environment: a profile created by "guix environment guix", as referenced by $GUIX_ENVIRONMENT, which I make the target of a symlink /var/guix/gcroots/per-user/mhw/environment-guix. When I update this GC root, I always keep the older GC root around until I'm absolutely certain that the new one works. With this GC root in hand, I can always load this build environment, without running guix, by simply sourcing its etc/profile file (using the first command of the script I quoted above). If Guix adds a new requirement, and I fail to notice before updating my git checkout, I can always roll back to an earlier checkout, rebuild it, and then use that to run "guix environment guix --ad-hoc ". Also, beware that when you build everything locally, which takes a *long* time (a couple of weeks of continuous building for a GNOME system on a Thinkpad X200), it's important to pass "--gc-keep-derivations=yes" and "--gc-keep-outputs=yes" to the Guix daemon. I have something close to this in the 'services' field of my OS config: (modify-services %desktop-services (guix-service-type config => (guix-configuration (inherit config) (use-substitutes? #f) (authorize-key? #f) (authorized-keys '()) (substitute-urls '()) (extra-options '("--gc-keep-derivations=yes" "--gc-keep-outputs=yes"))))) I can say from long experience that with the methods outlined here, you can make arbitrary local changes to your Guix that affects *every* package built in Guix. I've gone through long periods of running Guix with additional patches deep in the early bootstrap. If more people are interested in using Guix in this way, the experience could probably be made much nicer. * * * In theory, the "--url", "--branch", and "--commit" to "guix pull" should allow this level of flexibility without the gotchas listed above, at least for those who are willing to put their branch of Guix on a public Git repo. However, I'm not sure that "guix pull" will actually work correctly if you make "rebuild-the-world" changes like the ones that Charles is asking about. I suspect this because of the bug I reported here: . Since I seem to be the only one using Guix in this way, the bug report didn't get attention. That bug was about "make as-derivation", but I guess it's likely that "guix pull" would be affected as well. Mark