`cabal install`: fails remotely, succeeds locally (with `build-tools: alex`)

TL;DR It seems that `cabal install BNFC-2.8.3` does not run `alex`, but `cabal get BNFC-2.8.3 && cd BNFC-2.8.3 && cabal install` does so. Consequently GHC-9.2.1-build fails in the former case but succeeds in the latter case.
What is then the truth value of _BNFC-2.8.3 builds with GHC-9.2.1_ ?

This question came up in the wild, when I was investigating whether `BNFC-2.8.3` builds with GHC 9.2.1.

### 1. Fails when directly installing from hackage
```
$ cabal install -w ghc-9.2.1 BNFC-2.8.3
...
[ 16 of 104] Compiling LexBNF ( dist/build/bnfc/bnfc-tmp/LexBNF.hs, dist/build/bnfc/bnfc-tmp/LexBNF.o )

dist/build/bnfc/bnfc-tmp/LexBNF.hs:405:50: error:
• Couldn't match expected type ‘Int16#’ with actual type ‘Int#’
• In the fifth argument of ‘alex_scan_tkn’, namely ‘sc’
```

### 2. Succeeds when first downloading
```
$ cabal get BNFC-2.8.3
Unpacking to BNFC-2.8.3/
$ cd BNFC-2.8.3
$ cabal install -w ghc-9.2.1
...
[ 16 of 104] Compiling LexBNF ( dist/build/bnfc/bnfc-tmp/LexBNF.hs, dist/build/bnfc/bnfc-tmp/LexBNF.o )
...
Linking dist/build/bnfc/bnfc ...
```
WAT?

Installation succeeds when `LexBNF.x` is processed by `alex-3.2.6`, which is my installed version:
```
$ alex --version
Alex version 3.2.6, (c) 2003 Chris Dornan and Simon Marlow
```
The plan for the local install indeed contains `alex-3.2.6`:
```
$ cabal-plan
...
alex-3.2.6
[alex-3.2.6:exe:"alex"]
├─ array-0.5.4.0 ┄┄
├─ base-4.16.0.0 ┄┄
├─ containers-0.6.5.1 ┄┄
└─ directory-1.3.6.2 ┄┄
...
```
These are the versions of `LexBNF.hs` in the directory structure:
```
$ find . -name "LexBNF.hs" -exec ls -l {} \;
76062 Aug 27 2019 ./dist/build/unit-tests/unit-tests-tmp/LexBNF.hs
76062 Aug 27 2019 ./dist/build/bnfc/bnfc-tmp/LexBNF.hs
76275 Nov 9 22:42 ./dist-newstyle/build/x86_64-osx/ghc-9.2.1/BNFC-2.8.3/x/bnfc/build/bnfc/bnfc-tmp/LexBNF.hs
69884 Aug 27 2019 ./src/LexBNF.hs
```
The third has been created during build by `alex-3.2.6`.

### Further analysis of remote install

Note that constraining `alex == 3.2.6` does not help with the remote install:
```
$ cabal install -w ghc-9.2.1 BNFC-2.8.3 --constraint='any.alex==3.2.6'
((SAME RESULT)
```

It is noteworthy that the package contains both:
- `LexBNF.x`
- `LexBNF.hs` created with some `alex < 3.2.6`

More precisely, the tarball has:
```
BNFC-2.8.3/dist/build/unit-tests/unit-tests-tmp/LexBNF.hs
BNFC-2.8.3/dist/build/bnfc/bnfc-tmp/LexBNF.hs
BNFC-2.8.3/src/LexBNF.x
BNFC-2.8.3/src/LexBNF.hs
```

Some excerpts from `-v3`:
```
Resolving dependencies...
targets: BNFC
constraints:
...
any.alex ==3.2.6 (command line flag)
...
[_41] trying: BNFC:alex:exe.alex-3.2.6 (dependency of BNFC)
...
[_56] done
Elaborating the install plan...
Component graph for alex-3.2.6: component exe:alex
component lx-3.2.6-12b0a501
include array-0.5.4.0
include base-4.16.0.0
include containers-0.6.5.1
include directory-1.3.6.2
unit lx-3.2.6-12b0a501
include array-0.5.4.0
include base-4.16.0.0
include containers-0.6.5.1
include directory-1.3.6.2
...
```
Here, we break to remember that the Grinch stole the vowels from `alex`, just leaving us `lx` (#7209).
```
Configured alex-3.2.6 (lx-3.2.6-12b0a501)
array-0.5.4.0
base-4.16.0.0
containers-0.6.5.1
directory-1.3.6.2
...
Configured BNFC-2.8.3 (BNFC-2.8.3-87063006)
...
lx-3.2.6-12b0a501
...
Installed alex-3.2.6 (lx-3.2.6-12b0a501)
...
((REPETITIONS of this...))
...
Build profile: -w ghc-9.2.1 -O1
In order, the following will be built:
- BNFC-2.8.3-87063006 (exe:bnfc) (requires build)
- BNFC-2.8.3-a710c271 (lib) (requires build)
...
Finalized package description:
...
build-depends:
array >=0 && ==0.5.4.0,
base (>=4.6 && <5) && ==4.16.0.0
...
executable bnfc
main-is: Main.hs
build-tools: alex >=0, happy >=0
```
We break to wonder why no constraint on `alex` made it into the final description.
```
...
Searching for alex in path.
Found alex at /Users/abel/.cabal/store/ghc-9.2.1/lx-3.2.6-12b0a501/bin/alex
/Users/abel/.cabal/store/ghc-9.2.1/lx-3.2.6-12b0a501/bin/alex --version
/Users/abel/.cabal/store/ghc-9.2.1/lx-3.2.6-12b0a501/bin/alex is version 3.2.6
...
Environment: ... ("PATH","/Users/abel/.cabal/store/ghc-9.2.1/lx-3.2.6-12b0a501/bin:/Users/abel/.cabal/store/ghc-9.2.1/hppy-1.20.0-d456cdf9/bin:...
...
Using alex version 3.2.6 found on system at:
/Users/abel/.cabal/store/ghc-9.2.1/lx-3.2.6-12b0a501/bin/alex
...
creating dist/build/bnfc/bnfc-tmp
...
/usr/local/bin/ghc-9.2.1 --make ... -outputdir dist/build/bnfc/bnfc-tmp ... src/Main.hs Paths_BNFC LexBNF ...
...
[ 15 of 104] Compiling ErrM ( src/ErrM.hs, dist/build/bnfc/bnfc-tmp/ErrM.o )
[ 16 of 104] Compiling LexBNF ( dist/build/bnfc/bnfc-tmp/LexBNF.hs, dist/build/bnfc/bnfc-tmp/LexBNF.o )

dist/build/bnfc/bnfc-tmp/LexBNF.hs:405:50: error:
• Couldn't match expected type ‘Int16#’ with actual type ‘Int#’
...
```
I did not see an invocation of `alex` in `-v3`. It seems that `LexBNF` is taken from the shipped `dist/build/bnfc/bnfc-tmp/`.