Skip to content
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.

Sign up for GitHub

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

Jump to bottom

How should we test cabal-install with internal libraries? #3257

Open
4 of 6 tasks
ezyang opened this issue Mar 31, 2016 · 0 comments
Open
4 of 6 tasks

How should we test cabal-install with internal libraries? #3257

ezyang opened this issue Mar 31, 2016 · 0 comments
Labels
cabal-install: other cabal-install: tests/integration-tests re: internal library Concerning internal libraries in packages

Comments

@ezyang
Copy link
Contributor

ezyang commented Mar 31, 2016

Convenience libraries (#3022) need some integration tests with cabal-install to make sure, e.g., cabal-install's dependency solver and builder can handle them correctly.

In the solver:

  • When public library depends on internal library, solver should know how to satisfy the internal library, and dependencies of internal library should be considered.
  • Conversely, when public library does NOT depend on library, dependencies of internal library should only be considered if the buildable stanza associated with it (e.g., a test suite or executable) is being built.

Known bugs:

  • The dependency solver doesn't correctly interpret a build-depends on an internal library as referring to that library. (CC @edsko, @grayjay and @kosmikus in case you know why this is happening)
  • Installation into sandbox fails during ABI computation.
  • Regression: the component graph no longer respects build-tools.

Haddock:

  • Does it work at all? Is the internal library known to Haddock? What does it display as?

Design changes?

  • Maybe we shouldn't put things that are not package names in build-depends, otherwise the dependency solver has to work around them specially, since they never have any sort of valid version range. Alternatives are to have a special syntax for internal dependencies but keep them in build-depends (for example, a special "internal" version range).
ezyang added a commit to ezyang/cabal that referenced this issue Mar 31, 2016
@ezyang
Fix build-tools ordering regression (haskell#3257, haskell#1541)
b2be87e 
When converting the component graph to operate in terms of UnitIds
instead of CNames I accidentally introduced a regression where we
stopped respecting build-tools when determining an ordering to
build things.  This commit fixes the regression (though perhaps
not in the most clean/performant way you could manage it.)  It
also fixes a latent bug if internal libraries aren't processed
in the correct order.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit to ezyang/cabal that referenced this issue Mar 31, 2016
@ezyang
Fix build-tools ordering regression (haskell#3257, haskell#1541)
6d0b43d 
When converting the component graph to operate in terms of UnitIds
instead of CNames I accidentally introduced a regression where we
stopped respecting build-tools when determining an ordering to
build things.  This commit fixes the regression (though perhaps
not in the most clean/performant way you could manage it.)  It
also fixes a latent bug if internal libraries aren't processed
in the correct order.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit to ezyang/cabal that referenced this issue Mar 31, 2016
@ezyang
Fix build-tools ordering regression (haskell#3257, haskell#1541)
eafad0d 
When converting the component graph to operate in terms of UnitIds
instead of CNames I accidentally introduced a regression where we
stopped respecting build-tools when determining an ordering to
build things.  This commit fixes the regression (though perhaps
not in the most clean/performant way you could manage it.)  It
also fixes a latent bug if internal libraries aren't processed
in the correct order.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit to ezyang/cabal that referenced this issue Mar 31, 2016
@ezyang
Fix build-tools ordering regression (haskell#3257, haskell#1541)
5588dc3 
When converting the component graph to operate in terms of UnitIds
instead of CNames I accidentally introduced a regression where we
stopped respecting build-tools when determining an ordering to
build things.  This commit fixes the regression (though perhaps
not in the most clean/performant way you could manage it.)  It
also fixes a latent bug if internal libraries aren't processed
in the correct order.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit to ezyang/cabal that referenced this issue Apr 1, 2016
@ezyang
Recompute package registration AFTER we install (haskell#3257).
2bd9e11 
It needs to be done afterwards, because we need to compute
the ABI hash as part of registration, which can't be done
unless all dependencies are registered, which could include
internal libraries.

This whole affair is very dodgy.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit that referenced this issue Apr 1, 2016
@ezyang
Fix build-tools ordering regression (#3257, #1541)
e3a3b01 
When converting the component graph to operate in terms of UnitIds
instead of CNames I accidentally introduced a regression where we
stopped respecting build-tools when determining an ordering to
build things.  This commit fixes the regression (though perhaps
not in the most clean/performant way you could manage it.)  It
also fixes a latent bug if internal libraries aren't processed
in the correct order.

Signed-off-by: Edward Z. Yang <[email protected]>
ezyang added a commit to ezyang/cabal that referenced this issue Apr 1, 2016
@ezyang
Recompute package registration AFTER we install (haskell#3257).
3ad22e5 
It needs to be done afterwards, because we need to compute
the ABI hash as part of registration, which can't be done
unless all dependencies are registered, which could include
internal libraries.

This whole affair is very dodgy.

Signed-off-by: Edward Z. Yang <[email protected]>
@ezyang ezyang mentioned this issue Apr 1, 2016
Merged
ezyang added a commit that referenced this issue Apr 1, 2016
@ezyang
Recompute package registration AFTER we install (#3257).
ca43460 
It needs to be done afterwards, because we need to compute
the ABI hash as part of registration, which can't be done
unless all dependencies are registered, which could include
internal libraries.

This whole affair is very dodgy.

Signed-off-by: Edward Z. Yang <[email protected]>
@ulysses4ever ulysses4ever changed the title Testing plan for cabal-install and convenience libraries How should we test cabal-install with internal libraries? Jul 17, 2022
@andreasabel andreasabel added the re: internal library Concerning internal libraries in packages label Feb 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
cabal-install: other cabal-install: tests/integration-tests re: internal library Concerning internal libraries in packages
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ezyang @andreasabel @ulysses4ever