CI: Attempt to enable tests for 9.6.3 windows #9425
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Oh yeah, I can remember that "ld.lld: error: undefined symbol: sayHi" message from last time we tried it. |
|
Note: both failing tests are already broken on ghc-9.4 and marked as such. So at least the way forward here is to extend that predicate to newer GHC versions. I can see the |
|
I fixed the |
mpickering
force-pushed
the
wip/windows-cli
branch
from
ca708b3 to
05e63fa
Compare
|
@Mikolaj Why does CI fail? |
|
It is stuck @mpickering, try to rebase + force push. |
|
Whatever you both did, it seems to run fine right now. |
|
I restarted the jobs, might have just been transient. |
|
I need reviews please |
|
Add the |
Kleidukos
approved these changes
Nov 16, 2023
Kleidukos
added
merge me
Mikolaj
approved these changes
Nov 16, 2023
There were two failing tests: 1. CCompilerOverride, was attempting to use gcc.exe rather than clang.exe without also overriding the C options which led to incorrect options being passed to gcc.exe. The fix is to override to clang.exe on ghc-9.4 or newer. 2. ForeignLibs exposes a bug in GHC (https://gitlab.haskell.org/ghc/ghc/-/issues/24185) and hence is skipped for GHCs newer than 9.4 where it was first introduced. Towards fixing haskell#8451, we just need to fix the shared library issue now.
Mikolaj
force-pushed
the
wip/windows-cli
branch
from
05e63fa to
0a177f3
Compare
mpickering
added a commit
to mpickering/cabal
that referenced
this pull request
Feb 1, 2024
…s with custom setup. The idea here is to pass a `--package-db` flag to `cabal-install` which contains just `Cabal` and `Cabal-syntax` of the specific version. This allows `cabal-install` tests to use the in-tree `Cabal` version, something which you can easily run into and get very confused about when writing tests. There are a few options which can be passed to `cabal-tests` executable to control which Cabal library you will test against. 1. --boot-cabal-lib specifies to use the Cabal library bundled with the test compiler, this is the default and existing behaviour of the testsuite. 2. --intree-cabal-lib=<root_dir> specifies to use Cabal and Cabal-syntax from a specific directory, and `--test-tmp` indicates where to put the package database they are built with. 3. --specific-cabal-lib=<VERSION> specifies to use a specific Cabal version from hackage (ie 3.10.2.0) and installs the package database into --test-tmp=<DIR> The end result is that changes in the Cabal library can be tested with cabal-install tests in the testsuite. There have been a number of confusing issues with people writing tests for changes in the Cabal library which never ran because of cabal-install tests always used the boot Cabal library (see haskell#9425 for one). Fixes haskell#9681
mpickering
added a commit
to mpickering/cabal
that referenced
this pull request
Feb 2, 2024
…s with custom setup. The idea here is to pass a `--package-db` flag to `cabal-install` which contains just `Cabal` and `Cabal-syntax` of the specific version. This allows `cabal-install` tests to use the in-tree `Cabal` version, something which you can easily run into and get very confused about when writing tests. There are a few options which can be passed to `cabal-tests` executable to control which Cabal library you will test against. 1. --boot-cabal-lib specifies to use the Cabal library bundled with the test compiler, this is the default and existing behaviour of the testsuite. 2. --intree-cabal-lib=<root_dir> specifies to use Cabal and Cabal-syntax from a specific directory, and `--test-tmp` indicates where to put the package database they are built with. 3. --specific-cabal-lib=<VERSION> specifies to use a specific Cabal version from hackage (ie 3.10.2.0) and installs the package database into --test-tmp=<DIR> The end result is that changes in the Cabal library can be tested with cabal-install tests in the testsuite. There have been a number of confusing issues with people writing tests for changes in the Cabal library which never ran because of cabal-install tests always used the boot Cabal library (see haskell#9425 for one). Fixes haskell#9681
mpickering
added a commit
to mpickering/cabal
that referenced
this pull request
Feb 20, 2024
…s with custom setup. The idea here is to pass a `--package-db` flag to `cabal-install` which contains just `Cabal` and `Cabal-syntax` of the specific version. This allows `cabal-install` tests to use the in-tree `Cabal` version, something which you can easily run into and get very confused about when writing tests. There are a few options which can be passed to `cabal-tests` executable to control which Cabal library you will test against. 1. --boot-cabal-lib specifies to use the Cabal library bundled with the test compiler, this is the default and existing behaviour of the testsuite. 2. --intree-cabal-lib=<root_dir> specifies to use Cabal and Cabal-syntax from a specific directory, and `--test-tmp` indicates where to put the package database they are built with. 3. --specific-cabal-lib=<VERSION> specifies to use a specific Cabal version from hackage (ie 3.10.2.0) and installs the package database into --test-tmp=<DIR> The end result is that changes in the Cabal library can be tested with cabal-install tests in the testsuite. There have been a number of confusing issues with people writing tests for changes in the Cabal library which never ran because of cabal-install tests always used the boot Cabal library (see haskell#9425 for one). Fixes haskell#9681
mpickering
added a commit
to mpickering/cabal
that referenced
this pull request
Feb 21, 2024
…s with custom setup. The idea here is to pass a `--package-db` flag to `cabal-install` which contains just `Cabal` and `Cabal-syntax` of the specific version. This allows `cabal-install` tests to use the in-tree `Cabal` version, something which you can easily run into and get very confused about when writing tests. There are a few options which can be passed to `cabal-tests` executable to control which Cabal library you will test against. 1. --boot-cabal-lib specifies to use the Cabal library bundled with the test compiler, this is the default and existing behaviour of the testsuite. 2. --intree-cabal-lib=<root_dir> specifies to use Cabal and Cabal-syntax from a specific directory, and `--test-tmp` indicates where to put the package database they are built with. 3. --specific-cabal-lib=<VERSION> specifies to use a specific Cabal version from hackage (ie 3.10.2.0) and installs the package database into --test-tmp=<DIR> The end result is that changes in the Cabal library can be tested with cabal-install tests in the testsuite. There have been a number of confusing issues with people writing tests for changes in the Cabal library which never ran because of cabal-install tests always used the boot Cabal library (see haskell#9425 for one). Fixes haskell#9681
mpickering
added a commit
to mpickering/cabal
that referenced
this pull request
Feb 21, 2024
…s with custom setup. The idea here is to pass a `--package-db` flag to `cabal-install` which contains just `Cabal` and `Cabal-syntax` of the specific version. This allows `cabal-install` tests to use the in-tree `Cabal` version, something which you can easily run into and get very confused about when writing tests. There are a few options which can be passed to `cabal-tests` executable to control which Cabal library you will test against. 1. --boot-cabal-lib specifies to use the Cabal library bundled with the test compiler, this is the default and existing behaviour of the testsuite. 2. --intree-cabal-lib=<root_dir> specifies to use Cabal and Cabal-syntax from a specific directory, and `--test-tmp` indicates where to put the package database they are built with. 3. --specific-cabal-lib=<VERSION> specifies to use a specific Cabal version from hackage (ie 3.10.2.0) and installs the package database into --test-tmp=<DIR> The end result is that changes in the Cabal library can be tested with cabal-install tests in the testsuite. There have been a number of confusing issues with people writing tests for changes in the Cabal library which never ran because of cabal-install tests always used the boot Cabal library (see haskell#9425 for one). Fixes haskell#9681
mpickering
added a commit
to mpickering/cabal
that referenced
this pull request
Feb 21, 2024
…s with custom setup. The idea here is to pass a `--package-db` flag to `cabal-install` which contains just `Cabal` and `Cabal-syntax` of the specific version. This allows `cabal-install` tests to use the in-tree `Cabal` version, something which you can easily run into and get very confused about when writing tests. There are a few options which can be passed to `cabal-tests` executable to control which Cabal library you will test against. 1. --boot-cabal-lib specifies to use the Cabal library bundled with the test compiler, this is the default and existing behaviour of the testsuite. 2. --intree-cabal-lib=<root_dir> specifies to use Cabal and Cabal-syntax from a specific directory, and `--test-tmp` indicates where to put the package database they are built with. 3. --specific-cabal-lib=<VERSION> specifies to use a specific Cabal version from hackage (ie 3.10.2.0) and installs the package database into --test-tmp=<DIR> The end result is that changes in the Cabal library can be tested with cabal-install tests in the testsuite. There have been a number of confusing issues with people writing tests for changes in the Cabal library which never ran because of cabal-install tests always used the boot Cabal library (see haskell#9425 for one). Fixes haskell#9681
mpickering
added a commit
to mpickering/cabal
that referenced
this pull request
Feb 22, 2024
…s with custom setup. The idea here is to pass a `--package-db` flag to `cabal-install` which contains just `Cabal` and `Cabal-syntax` of the specific version. This allows `cabal-install` tests to use the in-tree `Cabal` version, something which you can easily run into and get very confused about when writing tests. There are a few options which can be passed to `cabal-tests` executable to control which Cabal library you will test against. 1. --boot-cabal-lib specifies to use the Cabal library bundled with the test compiler, this is the default and existing behaviour of the testsuite. 2. --intree-cabal-lib=<root_dir> specifies to use Cabal and Cabal-syntax from a specific directory, and `--test-tmp` indicates where to put the package database they are built with. 3. --specific-cabal-lib=<VERSION> specifies to use a specific Cabal version from hackage (ie 3.10.2.0) and installs the package database into --test-tmp=<DIR> The end result is that changes in the Cabal library can be tested with cabal-install tests in the testsuite. There have been a number of confusing issues with people writing tests for changes in the Cabal library which never ran because of cabal-install tests always used the boot Cabal library (see haskell#9425 for one). Fixes haskell#9681
mpickering
added a commit
to mpickering/cabal
that referenced
this pull request
Feb 22, 2024
…s with custom setup. The idea here is to pass a `--package-db` flag to `cabal-install` which contains just `Cabal` and `Cabal-syntax` of the specific version. This allows `cabal-install` tests to use the in-tree `Cabal` version, something which you can easily run into and get very confused about when writing tests. There are a few options which can be passed to `cabal-tests` executable to control which Cabal library you will test against. 1. --boot-cabal-lib specifies to use the Cabal library bundled with the test compiler, this is the default and existing behaviour of the testsuite. 2. --intree-cabal-lib=<root_dir> specifies to use Cabal and Cabal-syntax from a specific directory, and `--test-tmp` indicates where to put the package database they are built with. 3. --specific-cabal-lib=<VERSION> specifies to use a specific Cabal version from hackage (ie 3.10.2.0) and installs the package database into --test-tmp=<DIR> The end result is that changes in the Cabal library can be tested with cabal-install tests in the testsuite. There have been a number of confusing issues with people writing tests for changes in the Cabal library which never ran because of cabal-install tests always used the boot Cabal library (see haskell#9425 for one). Fixes haskell#9681
mpickering
added a commit
to mpickering/cabal
that referenced
this pull request
Feb 22, 2024
…s with custom setup. The idea here is to pass a `--package-db` flag to `cabal-install` which contains just `Cabal` and `Cabal-syntax` of the specific version. This allows `cabal-install` tests to use the in-tree `Cabal` version, something which you can easily run into and get very confused about when writing tests. There are a few options which can be passed to `cabal-tests` executable to control which Cabal library you will test against. 1. --boot-cabal-lib specifies to use the Cabal library bundled with the test compiler, this is the default and existing behaviour of the testsuite. 2. --intree-cabal-lib=<root_dir> specifies to use Cabal and Cabal-syntax from a specific directory, and `--test-tmp` indicates where to put the package database they are built with. 3. --specific-cabal-lib=<VERSION> specifies to use a specific Cabal version from hackage (ie 3.10.2.0) and installs the package database into --test-tmp=<DIR> The end result is that changes in the Cabal library can be tested with cabal-install tests in the testsuite. There have been a number of confusing issues with people writing tests for changes in the Cabal library which never ran because of cabal-install tests always used the boot Cabal library (see haskell#9425 for one). Fixes haskell#9681
mpickering
added a commit
to mpickering/cabal
that referenced
this pull request
Feb 22, 2024
…s with custom setup. The idea here is to pass a `--package-db` flag to `cabal-install` which contains just `Cabal` and `Cabal-syntax` of the specific version. This allows `cabal-install` tests to use the in-tree `Cabal` version, something which you can easily run into and get very confused about when writing tests. There are a few options which can be passed to `cabal-tests` executable to control which Cabal library you will test against. 1. --boot-cabal-lib specifies to use the Cabal library bundled with the test compiler, this is the default and existing behaviour of the testsuite. 2. --intree-cabal-lib=<root_dir> specifies to use Cabal and Cabal-syntax from a specific directory, and `--test-tmp` indicates where to put the package database they are built with. 3. --specific-cabal-lib=<VERSION> specifies to use a specific Cabal version from hackage (ie 3.10.2.0) and installs the package database into --test-tmp=<DIR> The end result is that changes in the Cabal library can be tested with cabal-install tests in the testsuite. There have been a number of confusing issues with people writing tests for changes in the Cabal library which never ran because of cabal-install tests always used the boot Cabal library (see haskell#9425 for one). Fixes haskell#9681
mpickering
added a commit
to mpickering/cabal
that referenced
this pull request
Feb 23, 2024
…s with custom setup. The idea here is to pass a `--package-db` flag to `cabal-install` which contains just `Cabal` and `Cabal-syntax` of the specific version. This allows `cabal-install` tests to use the in-tree `Cabal` version, something which you can easily run into and get very confused about when writing tests. There are a few options which can be passed to `cabal-tests` executable to control which Cabal library you will test against. 1. --boot-cabal-lib specifies to use the Cabal library bundled with the test compiler, this is the default and existing behaviour of the testsuite. 2. --intree-cabal-lib=<root_dir> specifies to use Cabal and Cabal-syntax from a specific directory, and `--test-tmp` indicates where to put the package database they are built with. 3. --specific-cabal-lib=<VERSION> specifies to use a specific Cabal version from hackage (ie 3.10.2.0) and installs the package database into --test-tmp=<DIR> The end result is that changes in the Cabal library can be tested with cabal-install tests in the testsuite. There have been a number of confusing issues with people writing tests for changes in the Cabal library which never ran because of cabal-install tests always used the boot Cabal library (see haskell#9425 for one). Fixes haskell#9681
mpickering
added a commit
to mpickering/cabal
that referenced
this pull request
Feb 25, 2024
…s with custom setup. The idea here is to pass a `--package-db` flag to `cabal-install` which contains just `Cabal` and `Cabal-syntax` of the specific version. This allows `cabal-install` tests to use the in-tree `Cabal` version, something which you can easily run into and get very confused about when writing tests. There are a few options which can be passed to `cabal-tests` executable to control which Cabal library you will test against. 1. --boot-cabal-lib specifies to use the Cabal library bundled with the test compiler, this is the default and existing behaviour of the testsuite. 2. --intree-cabal-lib=<root_dir> specifies to use Cabal and Cabal-syntax from a specific directory, and `--test-tmp` indicates where to put the package database they are built with. 3. --specific-cabal-lib=<VERSION> specifies to use a specific Cabal version from hackage (ie 3.10.2.0) and installs the package database into --test-tmp=<DIR> The end result is that changes in the Cabal library can be tested with cabal-install tests in the testsuite. There have been a number of confusing issues with people writing tests for changes in the Cabal library which never ran because of cabal-install tests always used the boot Cabal library (see haskell#9425 for one). Fixes haskell#9681
mpickering
added a commit
to mpickering/cabal
that referenced
this pull request
Mar 1, 2024
…s with custom setup. The idea here is to pass a `--package-db` flag to `cabal-install` which contains just `Cabal` and `Cabal-syntax` of the specific version. This allows `cabal-install` tests to use the in-tree `Cabal` version, something which you can easily run into and get very confused about when writing tests. There are a few options which can be passed to `cabal-tests` executable to control which Cabal library you will test against. 1. --boot-cabal-lib specifies to use the Cabal library bundled with the test compiler, this is the default and existing behaviour of the testsuite. 2. --intree-cabal-lib=<root_dir> specifies to use Cabal and Cabal-syntax from a specific directory, and `--test-tmp` indicates where to put the package database they are built with. 3. --specific-cabal-lib=<VERSION> specifies to use a specific Cabal version from hackage (ie 3.10.2.0) and installs the package database into --test-tmp=<DIR> The end result is that changes in the Cabal library can be tested with cabal-install tests in the testsuite. There have been a number of confusing issues with people writing tests for changes in the Cabal library which never ran because of cabal-install tests always used the boot Cabal library (see haskell#9425 for one). Fixes haskell#9681
erikd
pushed a commit
to erikd/cabal
that referenced
this pull request
Apr 22, 2024
…s with custom setup. The idea here is to pass a `--package-db` flag to `cabal-install` which contains just `Cabal` and `Cabal-syntax` of the specific version. This allows `cabal-install` tests to use the in-tree `Cabal` version, something which you can easily run into and get very confused about when writing tests. There are a few options which can be passed to `cabal-tests` executable to control which Cabal library you will test against. 1. --boot-cabal-lib specifies to use the Cabal library bundled with the test compiler, this is the default and existing behaviour of the testsuite. 2. --intree-cabal-lib=<root_dir> specifies to use Cabal and Cabal-syntax from a specific directory, and `--test-tmp` indicates where to put the package database they are built with. 3. --specific-cabal-lib=<VERSION> specifies to use a specific Cabal version from hackage (ie 3.10.2.0) and installs the package database into --test-tmp=<DIR> The end result is that changes in the Cabal library can be tested with cabal-install tests in the testsuite. There have been a number of confusing issues with people writing tests for changes in the Cabal library which never ran because of cabal-install tests always used the boot Cabal library (see haskell#9425 for one). Fixes haskell#9681
mergify bot
pushed a commit
that referenced
this pull request
May 13, 2024
…s with custom setup. The idea here is to pass a `--package-db` flag to `cabal-install` which contains just `Cabal` and `Cabal-syntax` of the specific version. This allows `cabal-install` tests to use the in-tree `Cabal` version, something which you can easily run into and get very confused about when writing tests. There are a few options which can be passed to `cabal-tests` executable to control which Cabal library you will test against. 1. --boot-cabal-lib specifies to use the Cabal library bundled with the test compiler, this is the default and existing behaviour of the testsuite. 2. --intree-cabal-lib=<root_dir> specifies to use Cabal and Cabal-syntax from a specific directory, and `--test-tmp` indicates where to put the package database they are built with. 3. --specific-cabal-lib=<VERSION> specifies to use a specific Cabal version from hackage (ie 3.10.2.0) and installs the package database into --test-tmp=<DIR> The end result is that changes in the Cabal library can be tested with cabal-install tests in the testsuite. There have been a number of confusing issues with people writing tests for changes in the Cabal library which never ran because of cabal-install tests always used the boot Cabal library (see #9425 for one). Fixes #9681 (cherry picked from commit 716b109)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Here for testing whether these tests are still failing and hopefully debugging.