Main modules in .hsc files are not included in sdist

You shouldn't be using extra-source-files, but listing the modules in each executable section using something like

other-modules: Heval Hhp Hmanage Hxput Hxsel Utils

Putting the output of hsc2hs in a source tarball would be inappropriate, as it is system-dependent.

Including or not including extra-source-files makes no difference, as far as I can tell. It still builds fine and doesn't sdist fine.

other-modules: would not be useful, I don't think, since as I mentioned, each file is the module Main. If I add in the line "other-modules: Heval Hhp Hmanage Hxput Hxsel Utils" into each executable section - nothing changes. If I modify it to read "other-modules: Main" - nothing changes.

Certainly putting .hs files in the extra-source-files is incorrect.

There is a bug here however. The original description is inaccurate as it specifies

main-is:            Hslock.hsc

where the actual source at http://gorgias.mine.nu/repos/xmonad-utils uses

main-is:            Hslock.hs

This explains why the error message above is:

Setup: Hslock.hs doesn't exist

So, main-is: should always be a .hs or .lhs file and is relative to the hs-source-dirs:. When building we correctly find the src/Hslock.hsc and pre-process it. The bug is that in sdist we just look for Hslock.hs directly in the hs-source-dirs without considering pre-processors at all.

The current Distribution/Simple/SrcDist.hs code just does:

  withExe pkg_descr $ \ (Executable _ mainPath exeBi) -> do
    prepareDir verbosity targetDir pps [] exeBi
    srcMainFile <- findFile (hsSourceDirs exeBi) mainPath

So the mainPath is ignored for pre-processing purposes.

Sorry, I missed that.

It looks like the fix for #14 is incomplete, as Duncan says. I think that the .hs source files will be included in the source bundle without needing to be mentioned in extra-source-files. The bug is that the .hsc source file is not also included. I suppose you can work around that with

extra-source-files: src/Hslock.hsc

Replying to ross@soi.city.ac.uk:

I suppose you can work around that with {{{ extra-source-files: src/Hslock.hsc }}}

Hmm, no that won't work: it will still be looking for the missing .hs file. Main modules that need preprocessing don't work. There's the unpleasant workaround of having a trivial Main.hs that calls the other module, I guess.

I think it would be most intuitive if main-is always named the source file containing the Main module, i.e. if

main-is:  Hslock.hsc

worked for both build and sdist.

Main modules that need pre-processing half work. :-) The half that does not work is including them into the src tarball.

Perhaps we are free to change the interpretation of main-is when using pre-processors since due to the sdist bug it would have been hard for any existing packages to use that feature.

I think main-is is a bit of a wart. It specifies some kind of file name where all the other bits us a module name. This is reflected internally in the code where most of this stuff works in terms of module names and the main-is has to be hacked in. :-(

Replying to duncan:

Perhaps we are free to change the interpretation of main-is when using pre-processors since due to the sdist bug it would have been hard for any existing packages to use that feature.

The User's Guide describes the meaning I was proposing, so build must be buggy :-P

Replying to ross@soi.city.ac.uk:

I think it would be most intuitive if main-is always named the source file containing the Main module, i.e. if {{{ main-is: Hslock.hsc }}} worked for both build and sdist.

On reflection, I'm not so sure. In general when we have arbitrary pre-processors there may be a tree of files used to generate a source module/file. So it's right to name the module or ultimate file rather than one of the files used to generate it (if indeed it is generated from another file at all). So in the general case it is the only thing we can name.

It's also a good deal easier in the code, it means we do not have to pass into the per-compiler code where the pre-processed .hs/.lhs file is to be found (something we do not do for exposed/other-modules). It means the per-compiler build code can just assume the file has been generated and can be found in the search path.

So I'll take a look at fixing the src dist side of things, so that it finds the stuff used to generate the main .hs/.lhs and includes that into the tarball. It should be just a minor adaption on what the code does already for the other-modules.

Fixed but not yet documented.

Thu Jan 31 11:49:09 GMT 2008  Duncan Coutts <duncan@haskell.org>
  * Find original sources for main-is when creating sdist
  Also add a package sanity check that main-is must specify a .hs or .lhs file.
  So the bahaviour is now that main-is specifies the main source file, even if
  that is generated by a pre-processor. This isn't really a change in behaviour
  since previously if you specified main-is: main.hsc then it would try to
  pass the .hsc file to ghc dirctly which would not work. For ticket #14 things
  were fixed to that it would look for main.hsc if you used main-is: main.hs an
  that file did not exist directy. This completes the other half, of actually
  being able to make a src distribution. So this should fix bug #217.
  Note that this still needs some work, we do not run platform-independent
  preprocessors and put the result into the tarball for main-is files.
  Generally, main-is has been the second class citizen compared to normal
  modules. We should try and refactor so both use the same code paths.

Now documented too.