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.
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
Allow executables to have Main modules with other names #1847
Comments
Cabal does allow any filename for an executable. |
The problem is more subtle, and just bit someone again. The original ticket characterized it correctly, and this does not. cabal does not allow for arbitrary module names for executables -- i.e. whatever the file is named, the module must be named main. (this was the underlying cause of the confusion here: https://www.reddit.com/r/haskell/comments/3lax6y/discussion_thread_about_stack/cv5uv0p) |
@gbaz Try |
@ttuegel +1. |
Yes, ghc --make can handle this. As the original ticket this references stated, GHC does this, and Cabal does not, and the choice was made to preserve this behavior because the GHC main-is support is GHC specific, and it was desired to support "all compilers." At this point, I think that ship has well sailed in this regard, with regards to legacy compilers. And we can expect new compilers to provide this. Anyway, the linked post above illustrates how this behavior can end up being quite confusing. At a minimum we should perhaps hard fail if we can't find a Main module instead of providing |
@ttuegel I'm happy to look at this if you or someone else could toss me a few pointers regarding the easiest path to tackle it. |
@gbaz The main barrier to fixing this today is the fact that we (Cabal) have no idea what the module name in that file is. We could change the meaning of the |
if you point me to the relevant files in the cabal codebase even, I could have a think :-) and failing that, if there are no objections, i'll just upgrade that warning to an error. |
I just tried this, and no, GHC definitely cannot handle this. Observe:
On the other hand,
So, GHC cannot handle this automatically. Therefore, I don't think it's unreasonable to require the user to specify the name of module in a field such as
I agree it should be an error and not a warning, but that produced by GHC, so you'll have to patch it there. That would be good, but it doesn't really fix the problem for users of current versions. Actually, I think it should be an error to pass |
Relevant things to adding a |
oh yes, I meant ghc handles this with "main-is" and cabal does not :-) The way it appears to do so is that it infers the module name from the path given by "main-is". So I wonder if we couldn't just leverage this behavior in the cabal process... I'll have a look. |
@gbaz As I just demonstrated, GHC always assumes |
Ah, I think I see the issue. Cabal's "main-is" picks out a file. GHC's "main-is" picks out a module name perhaps? |
As per the manual: The normal rule in Haskell is that your program must supply a main function in module Main. When testing, it is often convenient to change which function is the "main" one, and the -main-is flag allows you to do so. The thing can be one of:
Strictly speaking, -main-is is not a link-phase flag at all; it has no effect on the link step. The flag must be specified when compiling the module containing the specified main function (e.g. module A in the latter two items above). It has no effect for other modules, and hence can safely be given to ghc --make. However, if all the modules are otherwise up to date, you may need to force recompilation both of the module where the new "main" is, and of the module where the "main" function used to be; ghc is not clever enough to figure out that they both need recompiling. You can force recompilation by removing the object file, or by using the -fforce-recomp flag. so what I would like to see is if we generate the ghc main-is flag to pick out the module name of the file which is also specified in the "main-is" flag or something? This is tricky because the semantics feel similar but do different things, lending to confusion. |
Cabal doesn't have access to the module name, and we can't safely infer it because that would break existing packages. Maybe you could modify the |
on the warning/error thing, ghc bug filed: https://ghc.haskell.org/trac/ghc/ticket/10895#ticket |
I think of There are only two ways to fix this:
I would much prefer (2). Cabal doesn't really have any business parsing hs files. (Well, being a build system, it kind of does, but that's a whole different kettle of fish.) |
Ok, the upstream GHC issue I filed is fixed, and given ezyang's last comment here, I don't think we want to do anything fancy. (1) is a pain, and (2) seems like overkill for something that doesn't really matter. So let's just improve the docs a bit, as per the above-PR I filed, and when that's done, close this. |
#5122 was merged, closing. |
Faced this issue in 2018 (this issue is from 2014 or even older). I couldn't understand why Cabal was not fixed to handle this. Is it because of the following:
I don't think it is possible to have divergent file names and module names, right? Whenever I've tried I get a compile error. |
@saurabhnanda: This issue came again up in GHC.
Unfortunately this is possible: The module name in a file Hence it's not possible to translate a cabal |
So the workaround for a main module that is called
|
Seems the work around doesn't work. I keep getting linker errors. |
@friedbrice : Do you have a small reproducer? Might want to share this. However, I don't know how the standing toward this feature is, whether the cabal team will make efforts to support it properly. (https://github.com/haskell/cabal/pull/5122/files) |
Originally #172. This ticket edited by @ttuegel on 2015-09-18 to include original problem description.
Query on haskell-cafe:
So in GHC it has this meaning:
In Cabal the main-is: field specifies the file name of the Main module.
GHC's -main-is flag is an extension to Haskell that is not supported by the other Haskell implementations.
The text was updated successfully, but these errors were encountered: