Save the unnecessary rebuild of libraries with profiling

[konn]

Suppose we had configured with library-profiling: true and executable-profiling: false, and had built executables without --executable-profiling option.

Then, if we wanted to take an executable profiling and passed --executable-profiling option to stack, then it unregisters all the library consisting stack-project (not all the dependencies) and rebuild them from scratch, due to the change of compiler flags.

I think this behaviour is not optimal; we have built libraries with profiling features (and have p_o files already) and only we had to rebuild is executables.

For example, suppose we have the following stack.yaml:

packages:
- core-libs-and-exe   # package with library and executables
- util-lib -and-exe   # another one
- super-lib-and-exe   # yet another

extra-deps:
- extra-dependent-package-0.1.0.0

build:
  library-profiling: true
  executable-profiling: false

If we have once successfully executed stack build, p_o objects are built.
But if we enter stack build --executable-profiling again, Stack will rebuild all libraries and executables of core-libs-and-exe, util-lib -and-exe and super-lib-and-exe, although extra-dependent-package will not be rebuilt since they have profiling object files.

My propose is just to avoid rebuild libraries if the library profiling had been already enabled but executable was not.

[mattaudesse]

Thanks @konn. Is this something you'd like to submit a PR for?

[konn]

@mattaudesse Thank you for rapid reply!

Unfortunately, I will be on a vacation since tomorrow for one week, and have no knowledge about Stack internals, so I don't have enough time at least until the end of this month.

[mattaudesse]

You're welcome! And there's no need to worry about timing (have a great vacation BTW) - I think the profiling UX has been an ongoing focus of discussion for awhile now.

I should add that we've already got quite a few (possibly-)related issues in the tracker:
#2684
#2285
#3798
#2984
This diff
and many more

I'm not sure if it's relevant to your workflow at all, but this thread describes a trick for people who frequently go back and forth between profiled and non-profiled builds:
#4032

[konn]

Thank you for the pointers! A trick to separate workdir seems working for my case, since vast majority of deps are already on Stackage LTS. I think I can use this as a tentative workaround until some official support will be implemented. Thanks!

[dbaynard]

@mattaudesse It would be good to close all those issues except one — would you like to take the lead?

[qrilka]

The problem of rebuilds will be resolved by #3922 and my manual tests of #4412 approve that

[mattaudesse]

@dbaynard sure, I can take a look but it'll probably be a few days before I'm able to focus any real attention on it - the Thanksgiving holiday here in the states is always a wacky time of year.

[qrilka]

Actually the mentioned #4412 didn't resolve the problem of rebuilds completely but in #4582 I add tests in 58c2cd7 and 4b316b8 specifically testing rebuilds with profiling

[mattaudesse]

In the interest of paring down the backlog I'm going to go ahead and close this issue - if you've arrived here from a search please refer to/continue the discussion at #4032.

Thanks again for the suggestion @konn!