angerman changed the topic of #haskell.nix to: https://input-output-hk.github.io/haskell.nix - alternative haskell infrastructure for nix; logs at https://logs.nix.samueldr.com/haskell.nix
proofofkeags_ has joined #haskell.nix
proofofkeags has quit [Ping timeout: 264 seconds]
proofofkeags__ has joined #haskell.nix
proofofkeags_ has quit [Ping timeout: 260 seconds]
proofofkeags_ has joined #haskell.nix
proofofkeags__ has quit [Remote host closed the connection]
proofofkeags__ has joined #haskell.nix
proofofkeags_ has quit [Ping timeout: 240 seconds]
proofofkeags_ has joined #haskell.nix
proofofkeags__ has quit [Ping timeout: 240 seconds]
hekkaidekapus_ is now known as hekkaidekapus
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined #haskell.nix
proofofkeags_ has quit [Ping timeout: 256 seconds]
acarrico has quit [Ping timeout: 256 seconds]
pie_ has quit [Ping timeout: 272 seconds]
pie_ has joined #haskell.nix
pie_ has quit [Ping timeout: 246 seconds]
pie_ has joined #haskell.nix
__monty__ has joined #haskell.nix
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined #haskell.nix
fendor_ has joined #haskell.nix
fendor has quit [Ping timeout: 265 seconds]
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined #haskell.nix
<hexagoxel> For `callCabalProjectToNix`, the `configureArgs` argument seems to be passed to the derivations of build-tools, so if you have a project where you need `-ftoggle-this-manual-flag` you recompile stuff like nix-tools-exe-cabal-to-nix
<hexagoxel> I guess this similar to the recent chat about which GHC versions are used for build-tools, but this is a bit over the top, isn't it?
<michaelpj> hexagoxel: that seems wrong
<michaelpj> are you sure?
<michaelpj> it doesn't look like it's used for anything except to be passed to the `cabal configure` call that's used to generate the plan for you project
<hexagoxel> I.. yeah it really seems that way. Let me re-check it carefully
<hexagoxel> so I have an expression "package-nix = callCabalProjectToNix { .. };"
<hexagoxel> if I nix-build that, it finishes immediately (because it is all built)
<hexagoxel> if I change it to 'package-nix = callCabalProjectToNix { configureArgs = "-ffoo"; .. };'
<hexagoxel> then it starts re-building
<hexagoxel> this is still inside a somewhat nested nix-expression, but I _think_ the fact that I just touched the location that calls `callCabalProjectToNix` makes it pretty clear this is not some unrelated argument-passing snafu (right?)
<__monty__> Is it actually building any of the nix-tools though? Looks like just config and GHC-env's maybe?
<michaelpj> /nix/store/nklaakp56yhyqd3w2yni89qqlvng6970-nix-tools.drv seems pretty damning though
<michaelpj> it's not that it was somehow cached before and now it's rebuilding it?
fendor_ is now known as fendor
<hexagoxel> I have tested it for three different configureArgs so far. For the first, I have it fully built. For the second, I have it built half-way. For the third, I have not started building anything.
<michaelpj> I just can't see how what you said could have caused you to build nix-tools when you wouldn't have needed to before
<hexagoxel> Switching to the other configureArg resumes the previous progress.
<hexagoxel> So the half-way one continues building the latter half
<hexagoxel> I doubt it is a caching thing
<michaelpj> the `nix-tools` derivation used by `callCabalProjectToNix` doesn't depend on `configureArgs`
<hexagoxel> Maybe my haskell-nix is a few commits behind master, I'll check that.
<__monty__> I figured nix-tools.drv was rebuilding only for those config and ghc-env builds.
<michaelpj> but it should be cached if you've done any IFD recently anyway?
<hexagoxel> I have one project where the configureArgs seem to not have the effect and one where it has. I am mildly confused at this point.
<hexagoxel> this probably is about caching/garbage-collection of some IFD. My dislike of IFDs increases.
<hexagoxel> anyway, thanks for the help
acarrico has joined #haskell.nix
<hexagoxel> oh, it seems I may be able to put a gcroot to the relevant nixpkgs.haskell-nix.nix-tools.ghcXXX
<hexagoxel> but the only way to reliably test this will be to do a nix-collect-garbage. Raaaahhh :)
<michaelpj> hexagoxel: you might be able to test with a little tactical use of `nix-store --delete`
acarrico has quit [Quit: Leaving.]
proofofkeags_ has joined #haskell.nix
__monty__ has quit [Quit: leaving]
proofofkeags__ has joined #haskell.nix
proofofkeags_ has quit [Ping timeout: 240 seconds]
hekkaidekapus_ has joined #haskell.nix
hekkaidekapus has quit [Ping timeout: 240 seconds]
hekkaidekapus_ is now known as hekkaidekapus
hekkaidekapus_ has joined #haskell.nix
hekkaidekapus has quit [Ping timeout: 240 seconds]