On Mon, Mar 19, 2018 at 02:21:35PM -0400, myg...@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.
--
