I ran into this issue with a project that built stack applications in a
temporary location - the project needed the ability to build relocate the
.stack-work directory outside an application's directory hierarchy. I ended
up having to move directories back and forth to workaround the problem.

I went through an exercise of converting work-dir from a relative path to
an either absolute or relative path:

 -- | The top-level Stackage configuration.
 data Config =
   Config {configStackRoot           :: !(Path Abs Dir)
          -- ^ ~/.stack more often than not
-         ,configWorkDir             :: !(Path Rel Dir)
+         ,configWorkDir             :: !(Either (Path Abs Dir) (Path Rel
Dir))
          -- ^ this allows to override .stack-work directory

and threading it throughout stack:

https://github.com/commercialhaskell/stack/issues/1731#issuecomment-243680114
https://github.com/commercialhaskell/stack/compare/master...mfine:mfine-abs-rel-work-dir

The changes are pretty woof, but to be able to get the .stack-work
directory relocated like this was awesome:

$ repos/hellos > ~/.local/bin/stack build --work-dir
/Users/mark/tmp/stack-work
Populated index cache.
Did not find .cabal file for stm-containers-0.2.11 with Git SHA of
9410bc0f41fe0b458f7c350ce4a5a17cdbe3f18e
Did not find .cabal file for kansas-comet-0.4 with Git SHA of
be4690cfa4a780f71d05182fe5c69bb4ae635bf7
Did not find .cabal file for hledger-lib-0.27 with Git SHA of
9ad40bc0d38fb9fa2a96e2f5211fef8e2b405222
Did not find .cabal file for blank-canvas-0.6 with Git SHA of
1ab8537279ad2dd4cf25f76527633d47e5b16a94
hellos-0.0.0: configure
Configuring hellos-0.0.0...
hellos-0.0.0: build
Preprocessing executable 'hellos' for hellos-0.0.0...
[1 of 1] Compiling Main             ( Main.hs,
/Users/mark/tmp/stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/hellos/hellos-tmp/Main.o
)
Linking
/Users/mark/tmp/stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/hellos/hellos
...
hellos-0.0.0: copy/register
Installing executable(s) in
/Users/mark/tmp/stack-work/install/x86_64-osx/lts-5.18/7.10.3/bin

$ repos/hellos > ~/.local/bin/stack exec hellos --work-dir
/Users/mark/tmp/stack-work
Setting phasers to stun... (port 3000) (ctrl-c to quit)
"CurrentDirectory
/Users/mark/tmp/stack-work/install/x86_64-osx/lts-5.18/7.10.3/share/x86_64-osx-ghc-7.10.3/hello-0.0.0"
"DataDir /Users/mark/repos/hellos"

Would love to see this make it into stack and would be willing to
contribute towards it!

Mark

On Sun, Feb 7, 2016 at 2:00 PM, Magnus Therning <[email protected]> wrote:

>
> Emanuel Borsboom writes:
>
> > I think it makes sense to accommodate this type of use case. The first
> step
> > would be to add support for consolidating all packages’ .stack-works
> into a
> > single one for the project. Way in the past, this was actually how Stack
> > always did it, so adding that back shouldn’t be too difficult. I’d
> actually
> > prefer that it were the standard behaviour. Once that’s done, we can make
> > --work-dir accept absolute paths and relative paths containing ...
> >
> > However, there's a wrinkle: there’s a Cabal issue that causes problems if
> > the dist directory is not within the package’s directory on Windows. We
> > haven’t put a lot of effort into finding a workaround, so it may be
> > possible to find a way around this or fix it upstream. If not, we’d have
> to
> > fall back to the current behaviour on Windows and would not be able to
> > support to support a .work-dir outside the project/package on that
> > platform. But I think some effort should be put into determining and
> fixing
> > the root cause, if possible.
> >
> > Can you document this in a Github issue so we don’t lose track of it? And
> > would you be interested in working on a pull request to implement it?
>
> Since I'm so slow someone else beat me to it :)
>
> https://github.com/commercialhaskell/stack/issues/1731
>
> I can also add that I made a naive attempt at simply change the type
>
> #+BEGIN_SRC haskell
> data Config =
>     ...
>     ,configWorkDir :: !(Path Abs Dir)
>     ...
> #+END_SRC
>
> and then continued to just work out the type errors that caused. I started
> with
> resolving it using ~resolveDir'~ (from ~Path.IO~) and continued from there
> with
> one type error at a time. After a while I ran into the mixed use of
> relative and
> absolute dirs in the source. In short, I gave up after getting the feeling
> that
> I really would need a better understanding of how the dirs all fit together
> before making this change.
>
> /M
>
> --
> Magnus Therning              OpenPGP: 0x927912051716CE39
> email: [email protected]   jabber: [email protected]
> twitter: magthe               http://therning.org/magnus
>
> Where the people fear the government you have tyranny.  Where the
> government fears the people you have liberty.
>      -- John Basil Barnhill
>
> --
> You received this message because you are subscribed to the Google Groups
> "haskell-stack" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/haskell-stack/874mdk41vm.fsf%40therning.org.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"haskell-stack" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/haskell-stack/CANRZ_fkihymZJjbKyveCnbLpGRT5DvYm5bKz2zHY__HNwt-gSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to