Cabal: RFC: reconsider build-type:custom for cabal-install

[hvr]

Currently, build-type:custom forces building executable & test components in cabal-install to be serialised.

On an Intel Core i7-3770/3.4GHz a full build (i.e. after rm -rf dist-newstyle) via cabal new-build --enable-tests takes

real    8m43.765s
user    8m55.672s
sys 0m8.896s

Whereas, when manually changing build-type:custom into build-type:simple, such a full build takes notably less time to complete:

real    4m57.386s
user    9m53.852s
sys 0m10.000s

From my POV, there's at least 3 options:

1. do nothing, leave things as is
2. figure out a way to retain component-build parallelism even with build-type:custom
3. modify cabal-install.cabal to use simple build-type (we use Setup.hs only for the purpose of generating a man-page)

[ezyang]

I support cabal-install not being a Custom build type. But I'll note that the intention was always to get component-build parallelism with Custom; I just didn't implement it because I didn't feel like fiddling with ProjectBuilding to teach it how to build "a custom setup", and SetupWrapper to teach it how to invoke a specific, pre-built executable.

[hvr]

Also note that the only reason we have a Setup.hs file for cabal-install is to generate and install the cabal.1 man-page; are there any cabal users who benefit from this?

-- WARNING to editors of this file:
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- At this moment (Cabal 1.23), whatever you write here must be
-- compatible with ALL Cabal libraries which we support bootstrapping
-- with.  This is because pre-setup-depends versions of cabal-install will
-- build Setup.hs against the version of Cabal which MATCHES the library
-- that cabal-install was built against.  There is no way of overriding
-- this behavior without bumping the required 'cabal-version' in our
-- Cabal file.  Travis will let you know if we fail to install from
-- tarball!

main :: IO ()
main = defaultMainWithHooks $ simpleUserHooks
  { postBuild = \ _ flags _ lbi ->
      buildManpage lbi (fromFlag $ buildVerbosity flags)
  , postCopy = \ _ flags pkg lbi ->
      installManpage pkg lbi (fromFlag $ copyVerbosity flags) (fromFlag $ copyDest flags)
  , postInst = \ _ flags pkg lbi ->
      installManpage pkg lbi (fromFlag $ installVerbosity flags) NoCopyDest
  }

buildManpage :: LocalBuildInfo -> Verbosity -> IO ()
buildManpage lbi verbosity = do
  let cabal = buildDir lbi </> "cabal/cabal"
      manpage = buildDir lbi </> "cabal/cabal.1"
  manpageHandle <- openFile manpage WriteMode
  notice verbosity ("Generating manual page " ++ manpage ++ " ...")
  _ <- runProcess cabal ["manpage"] Nothing Nothing Nothing (Just manpageHandle) Nothing
  return ()

installManpage :: PackageDescription -> LocalBuildInfo -> Verbosity -> CopyDest -> IO ()
installManpage pkg lbi verbosity copy = do
  let destDir = mandir (absoluteInstallDirs pkg lbi copy) </> "man1"
  installOrdinaryFiles verbosity destDir [(buildDir lbi </> "cabal", "cabal.1")]

As for distro-packagers, those can simply execute cabal manpage and redirect its output where they need it to be. They most likely have to move the cabal.1 file Setup.hs installs into a different place anyway.

[ezyang]

Yeah, I'd say distro packagers, but I also agree with what you say.

[23Skidoo]

I'm +1 on this, but I think that distro packagers won't know about cabal manpage, so I suggest that we put a pre-generated manpage into data-files and add a CI check that it is up to date.

[hvr]

@23Skidoo I think that extra-source-files might be better, as distro packagers typically pay attention to what's in the top-level source-tree, and that's where you often find pre-rendered man-pages

[phadej]

cabal-install is now build-type: Simple