On Thu, Jan 21, 2016 at 11:21:34AM +1100, Jookia wrote: > On Wed, Jan 20, 2016 at 11:26:14PM +0100, Ludovic Courtès wrote: > > Yes, I agree that this would be nice. > > I wonder how this could be implemented, any ideas? > > > OTOH, for things like GCC, once you start fiddling with the build tree, > > you quickly lose track of what state you’re in. > > > > My workflow has been: > > > > guix build foo -K > > # build fails > > cd /tmp/guix-build* > > source environment-variables > > # Fiddle with the build tree to get additional info about the problem > > # and a possible fix. > > # Write a phase that hopefully fixes the issue. > > # Try again. > > > > Since the ‘environment-variables’ file always contains the value of > > environment variables at the time where the build failed (rather than > > their initial value), it usually works quite well. > > This could be good enough for now but again this doesn't work with this like > builds that don't fail. My concrete example is wanting to patch software but > not > knowing how to get to the pre-patch state so I can then work from that in > testing which patches apply and which don't, or make my own.
My workflow for creating patches: $ tar xf $(guix build --source foo) # or, if the package is in your local source tree: $ tar xf $(./pre-inst-env guix build --source foo) $ cd foo && git init && git add -A && git commit -m "Initial commit" # make edits and commit them. Then: $ git format-patch It's not necessary to use git but it helps me keep track of my changes. > > > My 2¢, > > Ludo’. > > Cheers, > Jookia. >
