<div dir="ltr"><div>On the topic of cabal creating inconsistent environments: I keep seeing these issues on SO and elsewhere.</div><div>This thread was the last drop for me, and I started an RFC over on cabal bug tracker with a proposal to simply refuse to do the thing that is known to fail.</div><div><a href="https://github.com/haskell/cabal/issues/8483">https://github.com/haskell/cabal/issues/8483</a></div><div>Unfortunately, it's not going well  so far. See if you have something to contribute there.</div><div><br></div><div>--</div><div>Best, Artem<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 18 Sept 2022 at 12:47, Tom Ellis <<a href="mailto:tom-lists-haskell-cafe-2017@jaguarpaw.co.uk">tom-lists-haskell-cafe-2017@jaguarpaw.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ah, that's interesting Oleg, thanks.  I like the idea of Cabal being<br>
able to specify the exact mapping between modules and source files.<br>
<br>
Tom<br>
<br>
On Fri, Sep 16, 2022 at 04:05:53PM +0300, Oleg Grenrus wrote:<br>
> That is error generated by GHC.<br>
> <br>
> The culprit is `ghc --make` mode which discovers modules/files on its own.<br>
> <br>
> If there were a way to say (for Cabal to GHC) that use these files to<br>
> compile the component, and fail otherwise, then -Wmissing-home-modules<br>
> would turn into error.<br>
> <br>
> In fact, it would be great if it where possible to say that *this*<br>
> module is in *that* file, something like `MyFoo:src/MyFoo.hs`.<br>
> <br>
> That would also solve a problem of having same hs-source-dirs for<br>
> different components, as Cabal would be able to tell GHC that "don't<br>
> look for this modules locally, use dependencies". As currently GHC will<br>
> eagerly look for modules locally first. Always.<br>
> <br>
> - Oleg<br>
> <br>
> On 16.9.2022 12.23, Tom Ellis wrote:<br>
> > On Fri, Sep 16, 2022 at 10:47:47AM +0200, Volker Wysk wrote:<br>
> >> The cabal user guide says (in section 6.2.12): "Every module in the package<br>
> >> must be listed in one of other-modules, library:exposed-modules or<br>
> >> executable:main-is fields."<br>
> >><br>
> >> However, I only get a warning message, when I comment out the other-modules<br>
> >> field in my .cabal file. The program compiles. This is the message:<br>
> >><br>
> >> <no location info>: warning: [-Wmissing-home-modules]<br>
> >>     These modules are needed for compilation but not listed in your .cabal <br>
> >>     file's other-modules: <br>
> >>         Hsskripte Sicherung SicherungAktionen Text Wahl Zeit<br>
> >><br>
> >> Is it really necessary to specify all the imported modules? If so, why does<br>
> >> the program compile? Can that warning message be turned off?<br>
> > In response to all the sibling replies at once, is there a good reason<br>
> > for this behaviour?  Succeeding but then failing later with obscure<br>
> > errors (once the original warning message is nowhere to be seen) seems<br>
> > like the worst of all worlds.  Suppose cabal errored here and failed<br>
> > to proceed.  What would be the downside of that (besides backward<br>
> > incompatibility)?<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>