Skip to content

new-build doesn't build tests even when given --enable-tests #3996

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
23Skidoo opened this issue Oct 18, 2016 · 4 comments
Closed

new-build doesn't build tests even when given --enable-tests #3996

23Skidoo opened this issue Oct 18, 2016 · 4 comments

Comments

@23Skidoo
Copy link
Member

This is with current master. When I try to compile bloodhound's test suite with new-build --enable-tests it compiles all dependencies correctly, but ignores the actual test suite. Subsequent attempts to run cabal new-build have no effect, new-build tests doesn't work either. Maybe has something to do with bloodhound using build-type: Custom.

@23Skidoo 23Skidoo added this to the 2.0 milestone Oct 18, 2016
@23Skidoo
Copy link
Member Author

Example log:

$ cabal new-build -w ghc-7.10.3 --enable-tests
Resolving dependencies...
In order, the following will be built (use -v for more details):
 - QuickCheck-2.9.2 (lib) (requires build)
 - quickcheck-io-0.1.3 (lib) (requires build)
 - doctest-prop-0.2.0.1 (lib) (requires build)
 - hspec-core-2.2.4 (lib) (requires build)
Configuring QuickCheck-2.9.2 (lib)...
Building QuickCheck-2.9.2 (lib)...
Configuring doctest-prop-0.2.0.1 (lib)...
Configuring quickcheck-io-0.1.3 (lib)...
Building doctest-prop-0.2.0.1 (lib)...
Building quickcheck-io-0.1.3 (lib)...
Configuring hspec-core-2.2.4 (lib)...
Building hspec-core-2.2.4 (lib)...
$ cabal new-build -w ghc-7.10.3 --enable-tests    
Up to date
$ cabal new-build -w ghc-7.10.3 --enable-tests tests
Up to date
$ cabal new-build -w ghc-7.10.3 tests               
Resolving dependencies...
Up to date

The -v3 log is here.

@dcoutts
Copy link
Contributor

dcoutts commented Oct 18, 2016

I think I've seen the same behaviour in a couple other packages. The behaviour appears to be that there's some problematic package and then one pass or other (probably the pruning of the plan to the targets) prunes everything that depends on that problematic package. This may be due to a dep closure failure being treated incorrectly (returning [] rather than failing), or something similar.

The same problem can be observed in the binary-serialise-cbor package, with one of the test suites that depends on the store package.

So I suggest tracing the planning code that does the pruning to targets, and perhaps adding some sanity check before pruning to check we don't have any dangling deps or other weirdness.

@ezyang
Copy link
Contributor

ezyang commented Oct 19, 2016

This may be due to a dep closure failure being treated incorrectly

Yeah, uh, we should not do that ;)

dcoutts added a commit to dcoutts/cabal that referenced this issue Oct 21, 2016
It turns out that the install plan elaboration is constructing cyclic
plans in some cases. The effect is that executing the plan simply misses
out anything that depends on the packages involved in the cycle. This is
probably the cause of haskell#3996

With this patch such cases will fail with an assertion such as:

internal error in InstallPlan.fromSolverInstallPlanWithProgress:
The following packages are involved in a dependency cycle
hspec-discover-2.3.1-da63d0b4e952e7949a113646e4af0aac925a4d864a1db650..

The cause is clearly in the caller of fromSolverInstallPlanWithProgress
and the only caller of that is ProjectPlanning.elaborateInstallPlan.
The problem appears to be to do with the intra-package dependencies.
@dcoutts
Copy link
Contributor

dcoutts commented Oct 21, 2016

So I think I have a diagnosis. At least it's a diagnosis for a similar problem that I can reproduce. It's incorrect construction of the elaborated plan in the first place (cycles).

ezyang added a commit to ezyang/cabal that referenced this issue Oct 21, 2016
In the old code, we assumed that only libraries could get
installed, but with executable dependencies this is no
longer true.  Handle it correctly.

This bug caused cycles in the elaborated install plan which
could cause dependency closure to fail, resulting in
weird errors.

Fixes haskell#3996.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit to ezyang/cabal that referenced this issue Oct 21, 2016
In the old code, we assumed that only libraries could get
installed, but with executable dependencies this is no
longer true.  Handle it correctly.

This bug caused cycles in the elaborated install plan which
could cause dependency closure to fail, resulting in
weird errors.

Fixes haskell#3996.

Signed-off-by: Edward Z. Yang <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants