Cache the profiling versions of dependent libraries.

[recursion-ninja]

It would be great if we could locally cache the profiling libraries of all the dependencies, because switching between profiling and non-profiling versions of my application is currently taking an hour and a half to perform the re-download, build, configure, copy/register process for all the dependent libraries.

I feel like after I've built once without profiling and once with profiling, stack shouldn't have to perform the onerous dependency re-download, build, configure, copy/register process when switching between a profiling and non-profiling build.

[borsboom]

The profiling libraries for snapshot packages are supposed to be cached. If they're not, that's a bug, in which case please re-open this issue.

For local extra-deps, there is an initiative called "implicit snapshots" that will fix this (among other issues): #1265. Unfortunately it's been stalled for quite a while now. In the mean time, custom snapshots are a cumbersome way to achieve the same thing.

[recursion-ninja]

To make sure I understand you correctly, if my project requires specific dependencies listed in the extra-deps field of the stack.yaml file, I will have to suffer through a long rebuild process when transitioning for profiling and non-profiling builds until progress is made on the "implicit snapshots" front?

If so, it might be more time effective for me to contribute towards the "implicit snapshots" issue rather than waiting around for our application to build with profiling enabled.

[borsboom]

Your understanding is, indeed, correct. Using a custom snapshot may help you out in the mean time, though (because that way you won't need extra-deps anymore).

[recursion-ninja]

@borsboom Thank you very much for taking the time to clarify the cause of this issue I am experiencing. After my deadline at the end of February I'll assess how much time I can devote towards contributing to issue #1265.

[recursion-ninja]

Unfortunately, I have not been able to divert time away from work to rectify this as I hoped I might be able to two years ago.

However, it appears that there has been no movement by anyone on this after two years. Additionally, this seems like pretty basic functionality for a build system. Where is this on the priority queue?

[ntc2]

@recursion-ninja here's a related, still open issue, that includes a work around: #4032

It should also be pretty easy to implement a solution based on that work around (i.e. always have two stack work dirs, one for profiling builds and one for non-profiling builds).

[qrilka]

I didn't have a chance to try it out yet but theoretically new Pantry version of Stack in the current master should give you separately built/stored libraries with profiling