#427: how to access temporary build-files/logs? ----------------------------+----------------------------------------------- Reporter: claus | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.3 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * type: defect => enhancement Comment: Keeping the temporary directory should be easy. I'm not sure how it would help users experiment with patched files since presumably we have to unpack the tarball from fresh, the idea of randomly re-using old build temporary trees makes me rather nervous. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/427#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

Nothing random there, just the ability to continue from the point of failure. Your build log tells you what commands cabal used. One of them failed. You edit the command line to see whether you can fix the issue. But to run and test the modified commandline, you need the temporary build

#427: how to access temporary build-files/logs? ----------------------------+----------------------------------------------- Reporter: claus | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.3 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): Replying to [comment:2 claus]: directory in the state in which that previous command failed. Once your modified command succeeds, you know whether you need to fix your package or cabal or ghc or .. Normally we should use a new randomly generated temp directory, since we're creating tmp dirs inside of a globally writable dir. So the first issue for restarting a build like that is knowing what build dir to use. The next issue is that we would be re-running commands so that's not continuing from the point of failure. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/427#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

#427: how to access temporary build-files/logs? ----------------------------+----------------------------------------------- Reporter: claus | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.3 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): Keeping the build dir is easy, `--resume` is more or less impossible. It requires more than we can legitimately assume of the build system for the package in question. Of course if we don't have `--resume` then there is no need for any `--from-scratch` since it's the default case. Would it be useful to have a flag to keep the build dir but not allow automatic restarting of builds? If so it's not hard to do. We just don't delete the temp dir on failure and we report where the temp dir actually is. At that point you could `cd` to the dir fix things up and try a `cabal install` in that dir, but if you do that you're on your own. It's not the same as resuming the build from the point of failure, it's restarting from the beginning, though keeping whatever source changes you made. If the build system for that package is not idempotent then you're stuffed. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/427#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

#427: how to access temporary build-files/logs? ----------------------------+----------------------------------------------- Reporter: claus | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.3 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): It's not clear to me actually that a `cabal install foobar --keep-build- dir` is useful since it's not going to be default. It cannot be default since we cannot leave large build dirs around for all builds. Even just failing builds would be too many, we do not want to force all users to periodically clean up old failed build trees. Consider the senario: {{{ $ cabal install foobar }}} It fails, so you run it again: {{{ $ cabal install foobar --keep-build-dir ... cabal: build dir is at /tmp/foobar.34463/ }}} So now you can go there and try and fix it: {{{ $ cd /tmp/foobar.34463/ $ vim src/Foobar.hs $ cabal install }}} But in that case isn't it just the same workflow as: {{{ $ cabal install foobar }}} It fails, so you unpack it, fix it and install: {{{ $ cabal unpack foobar $ cd foobar-1.0/ $ vim src/Foobar.hs $ cabal install }}} In fact it has the exact same number of steps uses fewer obscure flags and it works right now (the unpack command is in the current darcs version). So perhaps the only thing we need to do is make it clear to hackers that they can `cabal unpack` to debug a failing build. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/427#comment:7 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects

#427: how to access temporary build-files/logs? ----------------------------+----------------------------------------------- Reporter: claus | Owner: Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: Cabal library | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.3 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): Unless anyone has comments to add to this, I'm inclined to close as wontfix. As mentioned in #comment:7 my analysis is that `--keep-build-dir` would not actually help anyone, given the existence of `cabal unpack`. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/427#comment:9 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects