buildDocs requires a "Main.hs" file

[mgsloan]

If there is no Main.hs file in the source directory, then haddock: No input file(s). ends up in the stdout file.

{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE ScopedTypeVariables #-}

import IdeSession

main :: IO ()
main = do
    sess <- initSession defaultSessionInitParams defaultSessionConfig
    let update x = updateSession sess x print
    -- If you change this path to "Main.hs", then it works.
    update (updateSourceFile "src/Main.hs" "main = return ()")
    update buildDoc
    print =<< getBuildDocStatus sess
    distDir <- getDistDir sess
    putStrLn =<< readFile (distDir ++ "/doc/ide-backend-doc.stdout")

Results in:

[1 of 1] Compiling Main
Just (ExitFailure 1)
haddock: No input file(s).

Pinging @snoyberg for prioritization / etc. Now that I know I just need to have a "Main.hs" file, my work on https://github.com/fpco/fpco/issues/3808 is unblocked, so I don't think this is urgent.

Side note: There's also some code in IdeSession.Cabal.configureAndBuild which special-cases the existence of Main.hs / Main.lhs. As far as I know, the particular paths used for modules shouldn't matter, so this may be a holdover from when Namespace/Module.hs paths were always used. However, that code seems to work fine even when there is no Main.hs. Still, maybe worth looking into.

[Mikolaj]

Actually, what happens, I think, is that if a module has module Main inside, but is not named Main.hs (or Main.lhs) [Edit: including its relative path from the source directory], it's ignored, but haddocks are still generated for all other modules.

Note that, on commandline, haddocks are by default generated only for library modules, not for executable's modules. I guess, I had this in mind and possible future options similar to cabal's --haddock-executables, but the resulting behaviour neither consistenltly includes nor consistently ignores the modules that are only involved in building the executable (even assuming we could determine this without a .cabal file).

Currently we have the updateTarget calls that sort-of suggest which modules are part of the libraries and which are a part of executables. But from some previous tickets I remember the suggestion to be pretty vague, so perhaps I should just simplify the code and either generate hadocks for all files or always exclude files with Main in them (regardless of the file name)?

@snoyberg: which would you prefer?

@mgsloan Thank you for having a look at the IdeSession.Cabal.configureAndBuild code. The special treatment of Main.hs and Main.lhs there is indeed necessary, because cabal insists that the main module be in Main.hs or Main.lhs, while ide-backend does not (potentially? at some point I think you renamed modules or files, but you don't need to any more, except when other modules depend on a module called Main).

[Mikolaj]

I mixed up the last paragraph: IIRC, cabal insists that the module be Main and GHC insists that the file be Main.hs or Main.lhs. Anyway, the code is needed.

[snoyberg]

@Mikolaj Please go ahead with supporting Main modules if possible. We should already be giving you just one file with a Main module in it, so it should be unambiguous, and I believe the behavior will match what the rest of the IDE is doing.