If we don't need a package, then we don't use cabal.project.local

[zlonast]

Describe the bug
I get a warning. ld: warning: directory not found for option '-L/opt/homebrew/Cellar/xz/5.2.5/lib'
I noticed that the build for mac os throws a warning.
Then I decided to create a cabal.project.local file with path /usr/local/Cellar/xz/5.2.5/lib and was surprised that the warning was still there.
It turned out that the package is no longer needed, but now the cabal does not see the changes from the cabal.project.local.

I have found some solutions. Not good but working.
If you remove or replace a package lzma in a cabal.project, then the warning disappears.

To Reproduce
Steps to reproduce the behavior:

cabal init

add to cabal.project (that path usually use in ubuntu)

packages:
  .

package lzma
  extra-include-dirs: /opt/homebrew/Cellar/xz/5.2.5/include
  extra-lib-dirs: /opt/homebrew/Cellar/xz/5.2.5/lib

add to cabal.project.local (that path usually use in mac os)

ignore-project: True

package lzma
  extra-include-dirs: /usr/local/Cellar/xz/5.2.5/include
  extra-lib-dirs: /usr/local/Cellar/xz/5.2.5/lib

add to .cabal (we need at least one lib who using lzma, if we want to get warning)

build-depends:    
        base >=4.7 && <5
      , servant-swagger-ui

$ cabal v2-build

Expected behavior
No warning.

System information
mac os
cabal 3.6.2.0
ghc 9.0.2

[andreabedini]

Interestingly I cannot reproduce this warning on Linux. Despite the fact that none of /opt/homebrew/Cellar/xz/5.2.5/lib or /usr/local/Cellar/xz/5.2.5/lib exists.

But the problem stands. extra-lib-dirs and extra-include-dirs have an "append" sematic and, as both cabal.project files get read, both (pairs of) directories get added. I can see this by looking at what flags cabal has used to build lzma.

❯ cat ~/.cabal/store/ghc-8.10.7/lzma-0.0.0.3-70b060e19676f1d44df5d8f3c6ad7ec67f4722b1337e11aba82ccc51c7d0ac44/cabal-hash.txt 
pkgid: lzma-0.0.0.3
component: ComponentLib
src: af8321c3511bde3e2745093fa3bd74c642e386db7d2e7c43b3a54814f1338144
pkg-config-deps: 
deps: base-4.14.3.0, bytestring-0.10.12.0
compilerid: ghc-8.10.7
platform: x86_64-linux
shared-lib: True
stripped-exe: False
debug-info: 0
extra-lib-dirs: /opt/homebrew/Cellar/xz/5.2.5/lib /usr/local/Cellar/xz/5.2.5/lib
extra-include-dirs: /opt/homebrew/Cellar/xz/5.2.5/include /usr/local/Cellar/xz/5.2.5/include

[Mikolaj]

So the problem is that project files have "append" sematics? I think this is expected and useful when people use their tiny ad-hoc cabal.project.local to supplement big checked-in cabal.project. However, this could be better documented and, perhaps, we could in addition permit "overwrite" semantics, e.g., with some special syntax, or with another file.

@zloilya: what are your thoughts as a (surprised) user?

[zlonast]

I think the package overwrite syntax would be a good solution for me.
But I didn't find any docs for the cabal.project.local, so it still has some magic to me.

[zlonast]

Initially, I just decided to go through the Nix-style Local Builds chapter, thinking that it should be rewritten(docs) in the future and maybe I should start playing with what was described in it.
I start with this thread issues6105

[Mikolaj]

Splendid. Please feel free to open tickets for concrete proposals, the smaller, the better. E.g., the overwrite syntax ticket, or "document that cabal.project and cabal.project.local have append semantics" once you determine there are no tickets opened for that already (or no documentation already somewhere or it can be improved).

[jneira]

side question: i wonder what is the semantics of ignore-project: true in a cabal.project.local. Clearly it is not ignoring the main cabal.project

[fgaz]

I think it doesn't have any effect when in a project file, like builddir and project-file, for the same reason as those