[GHC] #16072: All dependencies of packages must be explicitly listed when defining flavour packages

#16072: All dependencies of packages must be explicitly listed when defining flavour packages -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the Hadrian user guide, it explains that you can use the `packages` variable in order to describe what is built. However, unless you list all the dependencies of what you want to build also in `packages` then it will fail to build. For example, if I want to just build `ghctags` then I might try to modify `packages` to {{{ ghcTagsPackages stage = case stage of Stage2 -> [ghcTags] _ -> [] }}} but this will fail as I haven't listed any dependencies of `ghcTags` at all. The culprit here is the `contextDependencies` function. {{{ contextDependencies :: Context -> Action [Context] contextDependencies Context {..} = do depPkgs <- go [package] return [ Context depStage pkg way | pkg <- depPkgs, pkg /= package ] where depStage = min stage Stage1 go pkgs = do deps <- concatMapM step pkgs let newPkgs = nubOrd $ sort (deps ++ pkgs) if pkgs == newPkgs then return pkgs else go newPkgs step pkg = do deps <- pkgDependencies pkg active <- sort <$> stagePackages depStage return $ intersectOrd (compare . pkgName) active deps }}} Notice in the definition of `step`, the actual package dependencies are intersected with `stagePackages`. It is also unclear to me why this function is defined recursively as surely when we `need` one dependency, that will in turn `need` its dependencies and so on. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16072 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16072: All dependencies of packages must be explicitly listed when defining flavour packages -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Fixing this causes some problems because the way that windows specific packages (for example, win32) are not compiled on unix is by this mechanism. It would be much more robust for this check to be moved to the place where `win32` is built. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16072#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#16072: All dependencies of packages must be explicitly listed when defining flavour packages -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): I agree that having a more intelligent `packages` setting would be convenient, although I'm not sure what would be the best way forward.
It is also unclear to me why this function is defined recursively as surely when we `need` one dependency, that will in turn `need` its dependencies and so on.
This function doesn't `need` anything, it's purpose is to compute the list of transitive dependencies of a `Context`. I believe one of the call sites of this function does rely on transitive dependencies being included into the result, although I'm afraid I don't recall right now where exactly this call site is. It might have something to do with package registration/configuration. How is the current recursive definition problematic, apart from complexity? I don't think this is immediately relevant to this issue.
It would be much more robust for this check to be moved to the place where `win32` is built.
What do you mean? There is no one place where `win32` is built: several different build rules are involved in building `win32`, as any other package. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16072#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC