local options do not work with install on local packages (was: Run okay with profiling enabled, but installed exe has NO profiling enabled)

[complyue]

Describe the bug
Can't install profiling-enabled exe with cabal 3.2.0.0, while direct running works correctly.

To Reproduce
Steps to reproduce the behavior:

$ cabal v2-run --enable-profiling --enable-executable-profiling  exe:els -- +RTS --info                                  
Resolving dependencies...
Up to date
 [("GHC RTS", "YES")
 ,("GHC version", "8.8.3")
 ,("RTS way", "rts_thr_p")
 ,("Build platform", "x86_64-apple-darwin")
 ,("Build architecture", "x86_64")
 ,("Build OS", "darwin")
 ,("Build vendor", "apple")
 ,("Host platform", "x86_64-apple-darwin")
 ,("Host architecture", "x86_64")
 ,("Host OS", "darwin")
 ,("Host vendor", "apple")
 ,("Target platform", "x86_64-apple-darwin")
 ,("Target architecture", "x86_64")
 ,("Target OS", "darwin")
 ,("Target vendor", "apple")
 ,("Word size", "64")
 ,("Compiler unregisterised", "NO")
 ,("Tables next to code", "YES")
 ,("Flag -with-rtsopts", "-maxN31 -qg")
 ]
$ cabal v2-install --enable-profiling --overwrite-policy=always --enable-executable-profiling exe:els && els +RTS --info 
Wrote tarball sdist to
 ...
Resolving dependencies...
Up to date
Copying 'els'
 [("GHC RTS", "YES")
 ,("GHC version", "8.8.3")
 ,("RTS way", "rts_thr")
 ,("Build platform", "x86_64-apple-darwin")
 ,("Build architecture", "x86_64")
 ,("Build OS", "darwin")
 ,("Build vendor", "apple")
 ,("Host platform", "x86_64-apple-darwin")
 ,("Host architecture", "x86_64")
 ,("Host OS", "darwin")
 ,("Host vendor", "apple")
 ,("Target platform", "x86_64-apple-darwin")
 ,("Target architecture", "x86_64")
 ,("Target OS", "darwin")
 ,("Target vendor", "apple")
 ,("Word size", "64")
 ,("Compiler unregisterised", "NO")
 ,("Tables next to code", "YES")
 ,("Flag -with-rtsopts", "-maxN31 -qg")
 ]
$ els +RTS -p
els: the flag -p requires the program to be built with -prof
els: 
els: Usage: <prog> <args> [+RTS <rtsopts> | -RTS <args>] ... --RTS <args>
els: ...
$ 

Expected behavior
The built executable can have +RTS -p enabled

System information

• Operating system

macOS Mojave

• cabal, ghc versions

$ cabal --version
cabal-install version 3.2.0.0
compiled using version 3.2.0.0 of the Cabal library 
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.8.3

Additional context
Add any other context about the problem here.

[fendor]

Looks like a duplicate of #5982

[complyue]

In addition to the cmdl options being ignored (as with #5982), I also instrumented in the cabal.project.local for profiling, hope this add more information (or concerns) for the diagnostics.

$ cat cabal.project.local 

profiling: True
profiling-detail: all-functions

optimization: 0

$ cat cabal.project

-- Please change Cabal project settings per your needs

-- FOLLOWING CONTENTS GONNA BE OVERWRITTEN BY EPM --

--  * this file should be:
--  /fw/m3cyue/edh-universe/cabal.project

packages:
 ./e-wrks/edh/lossless-decimal/lossless-decimal.cabal
 ./e-wrks/edh/elr/elr.cabal
 ./e-wrks/edh/host.hs/edh.cabal
 ./e-wrks/nedh/host.hs/nedh.cabal
 ./e-wrks/sedh/host.hs/sedh.cabal
 ./e-wrks/hasdim/host.hs/hasdim.cabal
 ./e-wrks/haskit/host.hs/haskit.cabal
 ./e-wrks/els/host.hs/els.cabal
$ 

[complyue]

BTW, Albert Y.C. Lai suggests in a Cafe list mail that such a workaround should work, but seemingly not for my case.

https://mail.haskell.org/pipermail/haskell-cafe/2021-February/133453.html

[amigalemming]

Do you have profiling disabled globally in .cabal/config?

[complyue]

@amigalemming I'm not sure, here is the content:

$ cat .cabal/config | grep -e '^\s*--' -v


repository mirrors.tuna.tsinghua.edu.cn
  url: http://mirrors.tuna.tsinghua.edu.cn/hackage




remote-repo-cache: /Users/cyue/.cabal/packages
world-file: /Users/cyue/.cabal/world
extra-prog-path: /Users/cyue/.cabal/bin
build-summary: /Users/cyue/.cabal/logs/build.log
remote-build-reporting: anonymous
jobs: $ncpus
install-method: copy
installdir: /Users/cyue/.cabal/bin

haddock

init

install-dirs user

install-dirs global

program-locations

program-default-options
$

Did I?

[amigalemming]

On Thu, 4 Mar 2021, Compl Yue wrote: @amigalemming I'm not sure, here is the content: $ cat .cabal/config | grep -e '^\s*--' -v

I would grep for 'profil', but it looks like you have not touched the profiling settings.

[romanofski]

I actually tripped over this too when working on purebred-mua/purebred#299. Also not explicitly profiling disabled. What I thought was interesting was that setting profiling: True in my cabal.project.local would not have an effect and neither would --enable-library-profiling. And by affect I mean, that under dist-newstyle I find profiling information, but in the installed package under ~/.cabal/store just the normal libraries.

Even the build progress does not show that profiling is enabled. If I build with:

$ cabal new-install -p -j --overwrite-policy=always --lib purebred-icu

I get:

In order, the following will be built (use -v for more details):
 - purebred-0.1.0.0 (lib) (requires build)
 - purebred-icu-0.1.0.0 (lib) (requires build)

Using the workaround linked from the mailing list, I get:

In order, the following will be built (use -v for more details):
 - purebred-0.1.0.0 (lib)  --enable-profiling (requires build)
 - purebred-icu-0.1.0.0 (lib)  --enable-profiling (requires build)

Perhaps it has something to do with multiple packages that even the command line arguments are not applied? My config that enabled profiling:

packages: .
          ../purebred-icu

package *
  profiling: True

The one which does not enable does not have the package * line.

[Mikolaj]

That's a long shot, but it may be related to #7236, where static compilation works with cabal build, but is ignored with cabal install.

[fgaz]

I have an hypothesis for why this happens:

• v2-install sdists the packages before installing them
  • this means the packages are treated as remote packages
• command line options are equivalent to top-level cabal.project options
  • top-level cabal.project options apply to local packages
• => the cli and top-level options are not applied to v2-installed packages!

If that's true, a possible workaround could be to set the desired options per-package in cabal.project. I did not test this yet.

[fgaz]

I did a few tests and it looks like my hypothesis is correct.

---

Workaround

for every local package x, add this snippet to your cabal.project

package x
  profiling: True

The same applies for other flags.

edit: oops, I just noticed that a similar workaround was posted above (though that will apply to all dependencies too)

---

I'll edit the title to reflect this.
This is very likely to be a part of what's happening in #7236