From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pjotr Prins Subject: Re: [Orchestration][RFC] A simple draft for channels Date: Mon, 19 Mar 2018 19:31:27 +0100 Message-ID: <20180319183127.GA16931@thebird.nl> References: <87bmhq6ytg.fsf@mdc-berlin.de> <87shar5wp8.fsf@gmail.com> <20180319120400.GA13807@thebird.nl> <87d100ncy8.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1exzdK-0003Ur-Mi for guix-devel@gnu.org; Mon, 19 Mar 2018 14:35:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1exzdH-000051-CQ for guix-devel@gnu.org; Mon, 19 Mar 2018 14:35:46 -0400 Received: from mail.thebird.nl ([95.154.246.10]:56173) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1exzdH-0008Ve-5O for guix-devel@gnu.org; Mon, 19 Mar 2018 14:35:43 -0400 Content-Disposition: inline In-Reply-To: <87d100ncy8.fsf@gmail.com> 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+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: myglc2@gmail.com Cc: guix-devel@gnu.org, Ricardo Wurmus On Mon, Mar 19, 2018 at 02:21:35PM -0400, myglc2@gmail.com wrote: > > Moving from one to the other, however, is too complicated and error > > prone. I can do it, but no one else really wants to. Even with my > > explanations it proves to be a royal pain. > > How about making guix a submodule of the GeneNetwork repo? I don't like git submodules, unfortunately. I have plenty experience there, and often not good. It works as long as you don't update the modules ;) I am OK with two git trees, there is no tight coupling between GeneNetwork and Guix. But there is tight coupling between GUIX_PACKAGE_PATH (guix-bioinformatics tree) and guix. I could consider making guix-bioinformatics a module of guix. But I am sure I am in for pain there too. > > Now I need a way to no longer rebuild all .go files for Guix tree > > updates/changes. Not only between switching branches, but also when > > just running 'git pull' from Guix savannah. I find I have to do that > > very often. So often that I don't even try running make anymore > > without make clean. Anyone here share that experience? > > Yes the guix make does seem rather fragile ;-) So I usually do ... > > guix environment guix -M 4 -c 4 --ad-hoc help2man git strace > rm -fr /home/g1/.cache/guile/ccache/* > sudo git clean -dfx > git pull > ./bootstrap > ./configure --localstatedir=/var --sysconfdir=/etc > make -j 10 > make -j 10 check Mine is comparable, but even more rigorous: screen -S guix-build # I tend to build in screen env -i /bin/bash --login --noprofile --norc ./pre-inst-env guix environment guix --ad-hoc help2man git strace \ pkg-config less vim binutils coreutils grep guile guile-git guile-json \ gcc nss-certs --no-grafts bash # you may want this shell rm -rf autom4te.cache/ # to be sure make clean ./bootstrap ./configure --localstatedir=/var make clean # to be really sure make clean-go # to be even surer make -j (forget the make check) but, yes, the point is that I have to do this too often and it takes a long time. So much that I thrust my hand through the monitor every time I have to start again. It is costing me monitors. And there are problems, usually with package updates that go out of sync between my trees. > This takes a while but it avoids me chasing spurious errors caused by > clashes between the state of my build directory and the upstream > changes ;-) I think we agree. > > One thing I could do is split out 3 git repos for every use case and > > update these individually not triggering rebuilds. And when I deploy > > on other machines move the complete repo across with .go files. > > Have you considered a git-worktree for each of the development, testing > and production branches? Hmmm. That may be helpful. I should try that. Still does not solve my deployment problems. Pj. --