From: Danny Milosavljevic <dannym@scratchpost.org>
To: Giovanni Biscuolo <g@xelera.eu>
Cc: guix-devel@gnu.org
Subject: Re: Guix direct checkout hacking
Date: Sat, 16 Mar 2019 12:54:56 +0100 [thread overview]
Message-ID: <20190316125456.4db5c8dd@scratchpost.org> (raw)
In-Reply-To: <87y35ft638.fsf@roquette.mug.biscuolo.net>
[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]
Hi,
On Sat, 16 Mar 2019 12:24:27 +0100
Giovanni Biscuolo <g@xelera.eu> wrote:
> I regurarly "git pull" in $GUIX_CHECKOUT and then "guix environment
> guix": is it sufficient and necessary to "/.bootstrap" and then
> "/.configure" every time I enter the environment in order to have a
> working build environment?
Not really. Only if dependencies get added or removed, or some
variables in the Makefiles get added or removed.
Personally, I'm too lazy to bootstrap every time. But I ./configure
pretty often ("./configure --localstatedir=/var").
> Do I really need to "make check" every time I "activate" the devel
> environment or after every "git pull" of my $GUIX_CHECKOUT?
Not really, but later on, it's nice to know whether your change broke
something or whether it was broken to begin with. Personally, I don't
run "make check" until I need to. I often need to backtrack then :)
> Do I neeed to regurarly "make clean-go" to get rid of compiled .go or I
> can ignore this step? If this step should be regurarly done: when?
> (this is not documented, just my curiosity)
I never do exactly this, but that's because clean-go regularily leaves
".go" files anyway.
Why this is necessary in the first place:
The problem is that there's some inline-tracking missing in the guile
handler for go files, so it can happen that one go file inlined something
that is already changed in the other go file (especially with macros).
The former won't be automatically recompiled and then you get an ABI
mismatch / funny behavior / crashes at runtime.
In the real world, I don't delete all ".go" file every time--it would
take way too long to recompile.
But if there are strange things happening later, I delete them and
run "make" in order to rebuild them.
> I start the build daemon in the environment:
>
> sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild
I never do this since the build daemon almost never changes. So I just
use the system build daemon.
> error: failed to run download program '/home/giovanni/{git}/giovanni.biscuolo.net/guix/nix/scripts/download': Permission denied
Hmm, what are the permissions of that file?
Did you generate it using the same user ? (via ./configure, I think).
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-03-16 11:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-16 11:24 Guix direct checkout hacking Giovanni Biscuolo
2019-03-16 11:54 ` Danny Milosavljevic [this message]
2019-03-16 14:39 ` Giovanni Biscuolo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190316125456.4db5c8dd@scratchpost.org \
--to=dannym@scratchpost.org \
--cc=g@xelera.eu \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.