GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-05T14:36:55Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24491Add a --test-ways flag to hadrian2024-03-05T14:36:55ZTeo CamarasuAdd a --test-ways flag to hadrianThis is a small idea to improve hadrian. Have a `--test-ways=<way>(,<way>)*` flag that allows specifying multiple ways at the same time rather than having to use several `--test-way=way1 --test-way=way2` options.This is a small idea to improve hadrian. Have a `--test-ways=<way>(,<way>)*` flag that allows specifying multiple ways at the same time rather than having to use several `--test-way=way1 --test-way=way2` options.https://gitlab.haskell.org/ghc/ghc/-/issues/24451hadrian: New untracked dependencies after ghc-internal patch?2024-03-11T15:20:25ZAndreas Klebingerhadrian: New untracked dependencies after ghc-internal patch?## Summary
I got one of these errors that sounds like we try to load an interface file before it's compiled because hadrian doesn't track the dependencies correctly.
## Steps to reproduce
hadrian/build -j6 (for me anyway).
This was t...## Summary
I got one of these errors that sounds like we try to load an interface file before it's compiled because hadrian doesn't track the dependencies correctly.
## Steps to reproduce
hadrian/build -j6 (for me anyway).
This was the end of the output:
```
Command line: _build/stage0/bin/ghc -Wall -Wcompat -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage1/inplace/package.conf.d' '-this-unit-id base-4.19.0.0-inplace' '-this-package-name base' '-package-id ghc-internal-0.1.0.0-inplace' -i -i/home/andi/ghc_expose_overloaded_unfoldings/_build/stage1/libraries/base/build -i/home/andi/ghc_expose_overloaded_unfoldings/_build/stage1/libraries/base/build/autogen -i/home/andi/ghc_expose_overloaded_unfoldings/libraries/base/src -Irts/include -I_build/stage1/libraries/base/build -I/home/andi/ghc_expose_overloaded_unfoldings/libraries/ghc-internal/include -I/home/andi/ghc_expose_overloaded_unfoldings/_build/stage1/libraries/ghc-internal/build/include -I/home/andi/ghc_expose_overloaded_unfoldings/libraries/ghc-bignum/include/ -I/home/andi/ghc_expose_overloaded_unfoldings/_build/stage1/libraries/ghc-bignum/build/include/ -I/home/andi/ghc_expose_overloaded_unfoldings/rts/include -I/home/andi/ghc_expose_overloaded_unfoldings/_build/stage1/rts/build/include -optP-include -optP_build/stage1/libraries/base/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/base/build -fdiagnostics-color=always -this-unit-id base -XHaskell2010 -no-global-package-db -package-db=/home/andi/ghc_expose_overloaded_unfoldings/_build/stage1/inplace/package.conf.d -ghcversion-file=rts/include/ghcversion.h -ghcversion-file=rts/include/ghcversion.h -Wnoncanonical-monad-instances -optc-Wno-error=inline -c libraries/base/src/Data/Char.hs -o _build/stage1/libraries/base/build/Data/Char.p_o -O2 -H32m -haddock -Wno-deprecated-flags -Wno-trustworthy-safe
===> Command failed with error code: 1
/home/andi/ghc_expose_overloaded_unfoldings/_build/stage1/inplace/../libraries/ghc-internal/build/GHC/Err.p_hi
Declaration for errorWithoutStackTrace
Unfolding of errorWithoutStackTrace:
SomeException ErrorWithoutFlag
Failed to load interface for ‘GHC.Exception.Type’.
Perhaps you haven't installed the profiling libraries for package ‘ghc-internal-0.1.0.0’?
Use -v to see a list of the files searched for.
Cannot continue after interface file error
Command failed
Build failed.
```
## Expected behavior
No errors.
## Environment
* GHC version used:
Optional:
* Operating System:
* System Architecture:https://gitlab.haskell.org/ghc/ghc/-/issues/24431Cross-compiling seems to not pass CC through2024-02-29T12:00:43ZGreg SteuckCross-compiling seems to not pass CC throughI'm having trouble trying to bootstrap OpenBSD-aarch64 from OpenBSD-amd64. I do have a working cross-toolchain (courtesy of LLVM) but it looks like the plumbing in hadrian is not fully laid. At least, when running with
```
export MAKE=gm...I'm having trouble trying to bootstrap OpenBSD-aarch64 from OpenBSD-amd64. I do have a working cross-toolchain (courtesy of LLVM) but it looks like the plumbing in hadrian is not fully laid. At least, when running with
```
export MAKE=gmake \
AUTOCONF_VERSION=2.71 \
AUTOMAKE_VERSION=1.16 \
CC=/usr/local/bin/clang-13 \
LD=/usr/local/bin/ld.lld-13 \
NM=/usr/local/bin/llvm-nm-13 \
OBJDUMP=/usr/local/bin/llvm-objdump-13
./boot
./configure --target=aarch64-none-openbsd --with-cc=/usr/local/bin/clang-13
hadrian/build '*.*.ghc.link.opts+=-L/usr/local/lib' \
--docs=none \
--flavour=quickest \
-j stage1:exe:ghc-bin
```
I see the main configure succeed, but stage0 is already going off the rails when trying to configure the time library which shows in its config.log:
```
$ //home/greg/s/ghc/libraries/time/configure --with-compiler=ghc
'--prefix=${pkgroot}/..' 'CFLAGS=-Qunused-arguments -iquote
/home/greg/s/ghc/libraries/time -Qunused-arguments'
LDFLAGS=--target=aarch64-none-openbsd --host=aarch64-none-openbsd
--with-cc=clang CC=/usr/bin/clang
```
Which clearly mixed up the uses target value for host whereas the compiler is the one for host. This compiler promptly reports:
```
error: unable to create target: 'No available targets are compatible with triple "aarch64-none-openbsd"'
```
because it doesn't have support for aarch64. In fact, it's unclear, where `/usr/bin/clang` even came from. My `configure` command above didn't point at it. Moreover, top level config.log doesn't mention it.
If there's better cross-compilation documentation to follow than https://gitlab.haskell.org/ghc/ghc/-/wikis/building/cross-compiling, I'd love to read that.
Attaching the top level [config.log](/uploads/23b8a2e89089c4b0cc61c7709a59ce82/config.log)
and[time-config.log](/uploads/4f834f246cf60f0d3c1fe38f4d097703/time-config.log).Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/24391Add hadrian option for rerunning failed test2024-03-18T15:48:31ZJadeAdd hadrian option for rerunning failed testWhen you write a ghc patch and want to create a MR, you'd probably run all tests locally with `hadrian/build -j --freeze1 test`. You might run into a regression, where let's say `T001`, `T002` and `T003` fail.
You write some code to fix ...When you write a ghc patch and want to create a MR, you'd probably run all tests locally with `hadrian/build -j --freeze1 test`. You might run into a regression, where let's say `T001`, `T002` and `T003` fail.
You write some code to fix the regression and now you manually have to copy down `T001`, `T002` and `T003`.
It would be nicer, if hadrian, upon running all tests, created a file `failed_tests` which listed all the tests that previously failed and deletes them, when they pass again. Running them is also made easier with a flag `--only-run-failed` which only runs tests which previously failed.
An example workflow could then look like
```
<write ghc code>
hadrian/build -j test
- tests failed: A, B (failed_tests file has [A, B])
<write code to fix regression A>
hadrian/build -j --only-run-failed
- tests failed: B (failed_tests file has [B])
<fix regression B, adding regression C>
hadrian/build -j --only-run-failed
- all tests passed!
hadrian/build -j
- tests failed: C (failed_tests file has [C])
<fix C>
hadrian/build -j
- all tests passed!
```https://gitlab.haskell.org/ghc/ghc/-/issues/24387Hadrian uses deprecated way to set project file.2024-01-30T16:01:51ZAndreas KlebingerHadrian uses deprecated way to set project file.## Summary
On HEAD I get the warning:
```
Warning: Specifying an absolute path to the project file is deprecated. Use
--project-dir to set the project's directory.
```
when invoking hadrian.
I suspect this is a warning by cabal but ...## Summary
On HEAD I get the warning:
```
Warning: Specifying an absolute path to the project file is deprecated. Use
--project-dir to set the project's directory.
```
when invoking hadrian.
I suspect this is a warning by cabal but I have not investigated.
## Steps to reproduce
Invoke hadrian
## Expected behavior
No warnings
## Environment
* GHC version used: HEAD
* Cabal version: cabal-install version 3.11.0.0 (built from source not too long ago)Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24382Hadrian "resource busy" errors are more frequent2024-03-26T14:59:24Zsheafsam.derbyshire@gmail.comHadrian "resource busy" errors are more frequentI have been getting rather many `copyFile:atomicCopyFileContents:withReplacementFile:copyFileToHandle:openFile: resource busy (file is locked)
` errors in Hadrian when building GHC lately. I don't have a specific reproducer, but it seems...I have been getting rather many `copyFile:atomicCopyFileContents:withReplacementFile:copyFileToHandle:openFile: resource busy (file is locked)
` errors in Hadrian when building GHC lately. I don't have a specific reproducer, but it seems it got worse in the past couple of months, as I now have to restart the build several times over to get through all of these errors.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24365Intermittent hadrian exception: withFile: resource busy (file is locked)2024-01-29T07:09:22ZBryan Rbryan@haskell.foundationIntermittent hadrian exception: withFile: resource busy (file is locked)Not many in the last two weeks, though I think I've seen it before:
| json->>'id' | json->>'web_url' | json->>'runner.description' | date(json->>'created_at') |
|-------------|----...Not many in the last two weeks, though I think I've seen it before:
| json->>'id' | json->>'web_url' | json->>'runner.description' | date(json->>'created_at') |
|-------------|---------------------------------------------------|----------------------------------------------------|---------------------------|
| 1758509 | https://gitlab.haskell.org/ghc/ghc/-/jobs/1758509 | azure-ci-1__9d97fee6dfe8 | 2024-01-23 |
| 1757881 | https://gitlab.haskell.org/ghc/ghc/-/jobs/1757881 | aarch64-darwin-2_aarch64-darwin-2_cf5fc9331e7a | 2024-01-22 |
| 1748231 | https://gitlab.haskell.org/ghc/ghc/-/jobs/1748231 | aarch64-linux-2.zw3rk_aarch64-linux-2_379242e21d29 | 2024-01-09 |
Two of the occasions mention `stamp-ghc-bignum-1.3-inplace_dyn`; one of them mentions `stamp-ghc-9.9-inplace_dyn`. But see #20886: the filename may be a red herring. Or maybe not!
```
/---------------------------------------------------------------------------------\
| Successfully built library 'ghc-bignum' (Stage1, way v). |
| Library: _build/stage1/libraries/ghc-bignum/build/libHSghc-bignum-1.3-inplace.a |
| Library synopsis: GHC BigNum library. |
\---------------------------------------------------------------------------------/
Error when running Shake build system:
at want, called at src/Main.hs:126:44 in main:Main
* Depends on: test:all_deps
at apply1, called at src/Development/Shake/Internal/Rules/Rerun.hs:41:5 in shake-0.19.7-cd9c3e55acea68cf885a8c15ce0927a9c158686ecdfdc3cb2cfc3905a7237499:Development.Shake.Internal.Rules.Rerun
* Depends on: test:check-exact
at apply1, called at src/Development/Shake/Internal/Rules/Rerun.hs:41:5 in shake-0.19.7-cd9c3e55acea68cf885a8c15ce0927a9c158686ecdfdc3cb2cfc3905a7237499:Development.Shake.Internal.Rules.Rerun
* Depends on: _build/test/bin/check-exact
at need, called at src/Rules/Test.hs:163:17 in main:Rules.Test
* Depends on: _build/stage1/bin/check-exact
at need, called at src/Rules/Register.hs:86:5 in main:Rules.Register
* Depends on: _build/stage1/lib/i386-linux-ghc-9.9.20240123/libHSghc-bignum-1.3-inplace-ghc9.9.20240123.so
at need, called at src/Rules/Library.hs:83:5 in main:Rules.Library
* Depends on: _build/stage1/lib/package.conf.d/ghc-bignum-1.3-inplace.conf
at need, called at src/Rules/Register.hs:140:5 in main:Rules.Register
* Depends on: _build/stage1/libraries/ghc-bignum/build/stamp-ghc-bignum-1.3-inplace_dyn
* Raised the exception:
_build/stage1/libraries/ghc-bignum/build/stamp-ghc-bignum-1.3-inplace_dyn: withFile: resource busy (file is locked)
```https://gitlab.haskell.org/ghc/ghc/-/issues/24354Bootstrap of v9.6.4 Fails to Install Built libffi libs, Uses Build Directorie...2024-01-25T01:15:06ZSteve SmithBootstrap of v9.6.4 Fails to Install Built libffi libs, Uses Build Directories, Not DESTDIR Directory## Summary
A standard bootstrap build of `ghc` (MacPorts update attempt to version 9.6.4) shows that the installed libraries do not correctly link to `libffi`, but rather the nonexistent build directory:
```sh
otool -L /opt/local/lib/g...## Summary
A standard bootstrap build of `ghc` (MacPorts update attempt to version 9.6.4) shows that the installed libraries do not correctly link to `libffi`, but rather the nonexistent build directory:
```sh
otool -L /opt/local/lib/ghc-9.6.4/lib/x86_64-osx-ghc-9.6.4/libHSrts-1.0.2-ghc9.6.4.dylib
/opt/local/lib/ghc-9.6.4/lib/x86_64-osx-ghc-9.6.4/libHSrts-1.0.2-ghc9.6.4.dylib:
@rpath/libHSrts-1.0.2-ghc9.6.4.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1)
/opt/local/var/macports/build/_opt_local_ports_lang_ghc/ghc/work/ghc-9.6.4/_build/stage1/libffi/build/inst/lib/libffi.8.dylib (compatibility version 10.0.0, current version 10.2.0)
```
Note that a build of `ghc` version 9.6.3 following the exact same procedure does not have this issue:
```sh
otool -L /opt/local/lib/ghc-9.6.3/lib/x86_64-osx-ghc-9.6.3/libHSrts-1.0.2-ghc9.6.3.dylib
/opt/local/lib/ghc-9.6.3/lib/x86_64-osx-ghc-9.6.3/libHSrts-1.0.2-ghc9.6.3.dylib:
@rpath/libHSrts-1.0.2-ghc9.6.3.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.0.0)
@rpath/libffi.dylib (compatibility version 10.0.0, current version 10.2.0)
```
## Steps to reproduce
Follow the build instructions at https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian.
## Expected behavior
Correct linking of `libffi`.
## Environment
* GHC version used: 9.6.4
Optional:
* Operating System: macOS9.6.5ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/24289Enable documentation building in cross bindists2024-03-20T10:46:50ZMatthew PickeringEnable documentation building in cross bindistsThere appears to be no inherent reason why we can't build documentation in a cross bindists. The hadrian rules currently bake in some incorrect assumptions about stages of libraries we should generate documentation for but these rules ca...There appears to be no inherent reason why we can't build documentation in a cross bindists. The hadrian rules currently bake in some incorrect assumptions about stages of libraries we should generate documentation for but these rules can probably be generalised to allow documentation to be produced for cross bindists.https://gitlab.haskell.org/ghc/ghc/-/issues/24276The global package db directory of GHC has duplicate files (*.copy)2024-01-09T15:13:57ZOleg GrenrusThe global package db directory of GHC has duplicate files (*.copy)```
/opt/ghc/9.8.1/lib/ghc-9.8.1/lib/package.conf.d % ll
total 1272
-rw-r--r-- 1 phadej phadej 1788 loka 10 10:56 array-0.5.6.0-88aa.conf
-rw-rw-r-- 1 phadej phadej 1788 loka 10 10:56 array-0.5.6.0-88aa.conf....```
/opt/ghc/9.8.1/lib/ghc-9.8.1/lib/package.conf.d % ll
total 1272
-rw-r--r-- 1 phadej phadej 1788 loka 10 10:56 array-0.5.6.0-88aa.conf
-rw-rw-r-- 1 phadej phadej 1788 loka 10 10:56 array-0.5.6.0-88aa.conf.copy
```
I checked versions 9.4.6, 9.6.2 and 9.8.1. All have these `*.copy` files. The 9.2.8 doesn't have.Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/24214Hadrian does not rebuild _build/doc/html/users_guide/flags.html2024-01-22T10:50:36ZVladislav ZavialovHadrian does not rebuild _build/doc/html/users_guide/flags.html## Summary
Hadrian does not rebuild `_build/doc/html/users_guide/flags.html`
## Steps to reproduce
1. Build HTML docs (e.g. with `hadrian/build -j --flavour=Quick --freeze1 docs --docs=no-sphinx-pdfs`. The Quick flavor might be incide...## Summary
Hadrian does not rebuild `_build/doc/html/users_guide/flags.html`
## Steps to reproduce
1. Build HTML docs (e.g. with `hadrian/build -j --flavour=Quick --freeze1 docs --docs=no-sphinx-pdfs`. The Quick flavor might be incidental, it's just what I use during development)
2. Change `docs/users_guide/using-warnings.rst`, e.g. add a new warning flag or modify one of the `:shortdesc:` fields.
3. Rerun the command to build HTML docs.
4. There is no change in `flags.html`
## Expected behavior
I expected the change to be reflected in `flags.html`.ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/24207Toolchain.Target should not be serialized/cached by Hadrian2023-11-21T15:44:08ZRodrigo MesquitaToolchain.Target should not be serialized/cached by HadrianBy caching the `./configure` or `ghc-toolchain` generated `Toolchain.Target` in hadrian we run into awkard situations like #24199.
In !11621 we improve the error messages when the toolchain is stale, but, ultimately, the fix should be n...By caching the `./configure` or `ghc-toolchain` generated `Toolchain.Target` in hadrian we run into awkard situations like #24199.
In !11621 we improve the error messages when the toolchain is stale, but, ultimately, the fix should be not to cache the Target, as noted in the MR by @mpickering.Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/24192hadrian: Make the default build target binary-dist-dir2024-03-20T10:46:50ZMatthew Pickeringhadrian: Make the default build target binary-dist-dirThe current default build target builds everything possible to build with the build system.
It would be more precise to build the `binary-dist-dir` target, as to build everything which is needed by a binary distribution.
Downside: We ...The current default build target builds everything possible to build with the build system.
It would be more precise to build the `binary-dist-dir` target, as to build everything which is needed by a binary distribution.
Downside: We might not built everything, so things may fail to build.
Upside: This is currently what CI builds anyway (and it's fine) and it will centralise logic about which stage libraries to build depending on whether we are cross compiling or not (!11444).
Anyone have an opinion? If there are no comments I will execute this in !11444https://gitlab.haskell.org/ghc/ghc/-/issues/24156Better hadrian error when configure was not run2023-11-14T14:57:10ZKrzysztof GogolewskiBetter hadrian error when configure was not runIf you clone a new repository and run `./hadrian/build`, it says
```
$ ./hadrian/build
Up to date
Error, file does not exist and no rule available:
hadrian/cfg/system.config
Build failed.
```
This message is subpar, it'd be better t...If you clone a new repository and run `./hadrian/build`, it says
```
$ ./hadrian/build
Up to date
Error, file does not exist and no rule available:
hadrian/cfg/system.config
Build failed.
```
This message is subpar, it'd be better to suggest boot + configure.https://gitlab.haskell.org/ghc/ghc/-/issues/241219.8.1 hadrian installs libraries LICENSE files into /usr/lib64/ghc-9.8.1/shar...2023-10-31T15:02:42ZJens Petersen9.8.1 hadrian installs libraries LICENSE files into /usr/lib64/ghc-9.8.1/share/doc/x86_64-linux-ghc-9.8.1/*/## Summary
## Steps to reproduce
The general Fedora steps are in ghc9.8.spec here:
https://src.fedoraproject.org/rpms/ghc9.8/tree/rawhide
But currently it works around this problem by just removing the said files at the end.
So curren...## Summary
## Steps to reproduce
The general Fedora steps are in ghc9.8.spec here:
https://src.fedoraproject.org/rpms/ghc9.8/tree/rawhide
But currently it works around this problem by just removing the said files at the end.
So currently it is not a high priority - though the file path seems unsatisfactory to me.
## Expected behavior
The LICENSE files are platform dependent so they could be installed in `/usr/lib64/ghc-9.8.1/share/doc/*/` at least.
Normally they should live around `/usr/share/{doc,licenses}/ghc-9.8.1/*/` instead.
## Environment
* GHC version used: 9.8.1
Optional:
* Operating System: Fedora Linux
* System Architecture: x86_649.8.2Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24098Hadrian compiles GHC without interpreter even on platforms that support it2023-10-24T14:33:36ZIlias TsitsimpisHadrian compiles GHC without interpreter even on platforms that support itWhile compiling GHC 9.4.7 on mips64el, I noticed that GHC was compiled **without** interpreter support. In contrast, when compiling using the old make system (again on mips64el) GHC is compiled with interpreter support as expected.
Taki...While compiling GHC 9.4.7 on mips64el, I noticed that GHC was compiled **without** interpreter support. In contrast, when compiling using the old make system (again on mips64el) GHC is compiled with interpreter support as expected.
Taking a look at the code, we can see that Hadrian has a hard-coded list to decide which targets support GHCi (see https://gitlab.haskell.org/ghc/ghc/-/blob/00920f176b0235d5bb52a8e054d89a664f8938fe/hadrian/src/Oracles/Setting.hs#L289). In contrast, the old make build system has a different logic to decide which targets support GHCi (see https://gitlab.haskell.org/ghc/ghc/-/blob/00920f176b0235d5bb52a8e054d89a664f8938fe/mk/config.mk.in#L178). If I understand the code correctly, the old make build system enables GHCi on all platforms that support shared libraries, which means all platforms except for `powerpc-ibm-aix`, `x86_64-unknown-mingw32` and `i386-unknown-mingw32`.
Please consider extending Hadrian to use the same logic as the old build system, and compile GHC with interpreter support on all platforms that support shared libraries.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23999hadrian fails to re-generate dependencies when hs-boot files are modified2023-10-03T16:08:32ZMatthew Cravenclyring@gmail.comhadrian fails to re-generate dependencies when hs-boot files are modified## Steps to reproduce
1. Check out a clean `master`. (I was at b8e4fe2318798185228fb5f8214ba2384ac95b4f.)
2. Run `hadrian/build _bootFileDeps/stage0/libraries/filepath/build/System/OsPath.o -o _bootFileDeps`.
3. Add a silly `import Data...## Steps to reproduce
1. Check out a clean `master`. (I was at b8e4fe2318798185228fb5f8214ba2384ac95b4f.)
2. Run `hadrian/build _bootFileDeps/stage0/libraries/filepath/build/System/OsPath.o -o _bootFileDeps`.
3. Add a silly `import Data.ByteString.Builder ()` to `libraries/filepath/System/OsPath.hs-boot`.
4. Run the same command from step 2. This will fail with a message like the following:
<details>
```
libraries/filepath/System/OsPath.hs-boot:5:1: error:
Could not find module ‘Data.ByteString.Builder’
There are files missing in the ‘bytestring-0.11.5.1’ package,
try running 'ghc-pkg check'.
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
|
5 | import Data.ByteString.Builder ()
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
</details>
5. Delete `_bootFileDeps/stage0/libraries/filepath/.dependencies.mk`.
6. Run the same command from step 2. Now it succeeds again.
## Expected behavior
Hadrian should not use stale `.dependencies*` information.Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/23966[RFC] Top-level Configure should do nothing but give Hadrian info2024-03-19T14:12:42ZJohn Ericson[RFC] Top-level Configure should do nothing but give Hadrian info@alt-romes and @bgamari, I think this comports with your `ghc-toolchain` work / is already the plan?
It certainly comports with @hsyl20's work to make Hadrian deal with the `*.cabal.in` files.
Right now we have
```m4sh
AC_CONFIG_HEADE...@alt-romes and @bgamari, I think this comports with your `ghc-toolchain` work / is already the plan?
It certainly comports with @hsyl20's work to make Hadrian deal with the `*.cabal.in` files.
Right now we have
```m4sh
AC_CONFIG_HEADER(mk/config.h)
# This one is manually maintained.
AC_CONFIG_HEADER(compiler/ghc-llvm-version.h)
dnl manually outputted above, for reasons described there.
dnl AC_CONFIG_HEADER(rts/include/ghcversion.h)
...
AC_CONFIG_FILES([mk/system-cxx-std-lib-1.0.conf])
...
AC_CONFIG_FILES(
[ mk/project.mk
hadrian/cfg/system.config
hadrian/ghci-cabal
hadrian/ghci-multi-cabal
hadrian/ghci-stack
docs/users_guide/ghc_config.py
distrib/configure.ac
hadrian/cfg/default.host.target
hadrian/cfg/default.target
])
```
That means we should not have the top-level configure produce these files:
- Compiler proper
- [x] `compiler/ghc-llvm-version.h` !11490
- RTS; #17191 will have the RTS configure script produce these directly
- [x] `mk/config.h` --- #17191 will have the RTS configure script produce this directly
- [x] `rts/include/ghcversion.h` --- #17191 again
- Docs
- [x] `docs/users_guide/ghc_config.py`
- Misc install platform sensative for bindist; should GHC toolchain take care of any of these?
- [ ] `mk/system-cxx-std-lib-1.0.conf`
- [ ] `distrib/configure.ac` -- !12051
- [ ] `mk/project.mk` -- !12051
Note that I do think we should keep the `.in` files so they don't *have* to be built with Hadrian --- I don't want to make it harder to get rid of Hadrian later, I just want to break up and get rid of the top-level configure script more than I want to get rid of Hadrian.https://gitlab.haskell.org/ghc/ghc/-/issues/23951Test suite --only doesn't work for hard_hole_fits2023-09-19T15:02:16ZSimon Peyton JonesTest suite --only doesn't work for hard_hole_fitsI tried to test `hard_hole_fits` all by itself
```
hadrian/build test --skip=_build/stage0/** --skip=_build/stage1/** --docs=no-haddocks --only=hard_hole_fits
```
But alas it is a no-op:
```
...
SUMMARY for test run started at Wed Sep ...I tried to test `hard_hole_fits` all by itself
```
hadrian/build test --skip=_build/stage0/** --skip=_build/stage1/** --docs=no-haddocks --only=hard_hole_fits
```
But alas it is a no-op:
```
...
SUMMARY for test run started at Wed Sep 13 13:55:02 2023
0:00:00.100124 spent to go through
1 total tests, which gave rise to
3 test cases, of which
3 were skipped
0 had missing libraries
0 expected passes
0 expected failures
0 caused framework failures
0 caused framework warnings
0 unexpected passes
0 unexpected failures
0 unexpected stat failures
0 fragile tests
```
Can anyone explain why/help? @bgamari @mpickering @monoidal?
It's a pain because I want to add `--test-accept` to accept the new output, but I can't. I can't even do it by hand because I don't know exactly what flags are passed to GHC.https://gitlab.haskell.org/ghc/ghc/-/issues/23904Configuring C compiler and linker flags separately breaks cabal (and potentia...2023-08-29T14:18:14ZMatthew PickeringConfiguring C compiler and linker flags separately breaks cabal (and potentially other downstream)Cabal has the following logic which combines together the C compiler flags for the linker and C compiler flags. This isn't safe to do in general because the flags might not be accepted by both modes.
```
63 (ccProg, ccFlags) <- configu...Cabal has the following logic which combines together the C compiler flags for the linker and C compiler flags. This isn't safe to do in general because the flags might not be accepted by both modes.
```
63 (ccProg, ccFlags) <- configureCCompiler verbosity programDb
64 ccProgShort <- getShortPathName ccProg
65 -- The C compiler's compilation and linker flags (e.g.
66 -- "C compiler flags" and "Gcc Linker flags" from GHC) have already
67 -- been merged into ccFlags, so we set both CFLAGS and LDFLAGS
68 -- to ccFlags
```
As our configure script now checks more precisely whether a flag is accepted by the C compiler used normally or the C compiler used as a linker.. this combination logic is problematic.
I am beginning to wonder whether this approach is very wise at all, because there's no similar convention to CFLAGS to pass flags into configure scripts for use with the C compiler when used as a linker.9.10.1Matthew PickeringMatthew Pickering