I have trouble with this as it breaks expectations around directory structure mirroring the module hierarchy.
I would be very confused reading the source code of a project that availed of this feature as it would break my expectations of how to navigate to source files based on their module hierarchy. I'm not sure how the tool support is implemented in Vim, Emacs, Yi, Leksah etc., but changing this may break the tool's ability to provide jump to symbol. I imagine other unforeseen challenges with source dependency analysis elsewhere in the GHC toolchain may also arise if they assume that the directory layout reflects the module hierarchy. The Java toolchain certainly falls over when the corresponding package-flattening trick is performed on a Java codebase. The workarounds are viral and wind up complicating builds considerably. I could also be totally out to lunch here. > On Apr 25, 2014, at 13:17, Simon Marlow <marlo...@gmail.com> wrote: > > I want to propose a simple change to the -i flag for finding source files. > The problem we often have is that when you're writing code for a library that > lives deep in the module hierarchy, you end up needing a deep directory > structure, e.g. > > src/ > Graphics/ > UI/ > Gtk/ > Button.hs > Label.hs > ... > > where the top few layers are all empty. There have been proposals of > elaborate solutions for this in the past (module grafting etc.), but I want > to propose something really simple that would avoid this problem with minimal > additional complexity: > > ghc -iGraphics.UI.Gtk=src > > the meaning of this flag is that when searching for modules, ghc will look > for the module Graphics.UI.Gtk.Button in src/Button.hs, rather than > src/Graphics/UI/Gtk/Button.hs. The source file itself is unchanged: it still > begins with "module Graphics.UI.Gtk.Button ...". > > The implementation is only a few lines in the Finder (and probably rather > more in the manual and testsuite), but I wanted to get a sense of whether > people thought this would be a good idea, or if there's a better alternative > before I push it. > > Pros: > > - simple implementation (but Cabal needs mods, see below) > - solves the deep directory problem > > Cons: > > - It makes the rules about finding files a bit more complicated. > People need to find source files too, not just compilers. > - packages that want to be compatible with older compilers can't > use it yet. > - you can't use '=' in a source directory name (but we could pick > a different syntax if necessary) > - It won't work for Cabal packages until Cabal is modified to > support it (PreProcess and SrcDist and perhaps Haddock are the only > places affected, I think) > - Hackage will need to reject packages that use this feature without > also specifying ghc >= 7.10 and some cabal-version too. > - Are there other tools/libraries that will need changes? Leksah? > > Cheers, > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
