recompile calls ghc --make, but supplies the -i argument, which suppresses including the current directory in the search path. This means that one can't break up xmonad.hs into modules in their own .xmonad directory. I don't see any particularly good reason to prevent this, so here's a patch that removes the -i argument. An equivalent change would be to change "-i" to "-i.", which explicitly sets the search path, but the ghc docs state that this is the default anyway, so I think that removing it makes more sense.
On Wed, Jul 23, 2008 at 04:12:08PM -0600, Justin Bogner wrote:
recompile calls ghc --make, but supplies the -i argument, which suppresses including the current directory in the search path. This means that one can't break up xmonad.hs into modules in their own .xmonad directory.
I don't see any particularly good reason to prevent this, so here's a patch that removes the -i argument. An equivalent change would be to change "-i" to "-i.", which explicitly sets the search path, but the ghc docs state that this is the default anyway, so I think that removing it makes more sense.
This is not compatible with case-insensitive file systems, such as those on OS X. When the user writes 'import XMonad', GHC will attempt to use ~/.xmonad/xmonad.hs rather than the installed library module. Cheers, Spencer Janssen
Spencer Janssen wrote:
On Wed, Jul 23, 2008 at 04:12:08PM -0600, Justin Bogner wrote:
recompile calls ghc --make, but supplies the -i argument, which suppresses including the current directory in the search path. This means that one can't break up xmonad.hs into modules in their own .xmonad directory.
I don't see any particularly good reason to prevent this, so here's a patch that removes the -i argument. An equivalent change would be to change "-i" to "-i.", which explicitly sets the search path, but the ghc docs state that this is the default anyway, so I think that removing it makes more sense.
This is not compatible with case-insensitive file systems, such as those on OS X. When the user writes 'import XMonad', GHC will attempt to use ~/.xmonad/xmonad.hs rather than the installed library module.
Cheers, Spencer Janssen
The case sensitive default filesystem on OS X angers me once again. Personally, I've reformatted to the case sensitive version of HFS, but I can see how this would be a concern. If there is no way around this, I'm interested in making it work from within my xmonad.hs. I've tried using an OPTIONS_GHC pragma, but it doesn't seem to work. Is there something wrong with the following? {-# OPTIONS_GHC -i. #-} -- Justin Bogner
On Wed, Jul 23, 2008 at 10:54:52PM -0600, Justin Bogner wrote:
Spencer Janssen wrote:
On Wed, Jul 23, 2008 at 04:12:08PM -0600, Justin Bogner wrote:
recompile calls ghc --make, but supplies the -i argument, which suppresses including the current directory in the search path. This means that one can't break up xmonad.hs into modules in their own .xmonad directory.
I don't see any particularly good reason to prevent this, so here's a patch that removes the -i argument. An equivalent change would be to change "-i" to "-i.", which explicitly sets the search path, but the ghc docs state that this is the default anyway, so I think that removing it makes more sense.
This is not compatible with case-insensitive file systems, such as those on OS X. When the user writes 'import XMonad', GHC will attempt to use ~/.xmonad/xmonad.hs rather than the installed library module.
Cheers, Spencer Janssen
The case sensitive default filesystem on OS X angers me once again. Personally, I've reformatted to the case sensitive version of HFS, but I can see how this would be a concern.
If there is no way around this, I'm interested in making it work from within my xmonad.hs. I've tried using an OPTIONS_GHC pragma, but it doesn't seem to work. Is there something wrong with the following?
{-# OPTIONS_GHC -i. #-}
-- Justin Bogner
I think -i is a "static" flag -- flags that must be on the commandline, and can't be set in a pragma.
On 2008 Jul 24, at 3:42, Spencer Janssen wrote:
On Wed, Jul 23, 2008 at 10:54:52PM -0600, Justin Bogner wrote:
The case sensitive default filesystem on OS X angers me once again. Personally, I've reformatted to the case sensitive version of HFS, but I can see how this would be a concern.
Sadly, not everyone can do so; Adobe products tend to rely on case insensitivity.
{-# OPTIONS_GHC -i. #-}
I think -i is a "static" flag -- flags that must be on the commandline, and can't be set in a pragma.
Can xmonad look for an environment variable containing options? Say, if $XMONAD_GHC_OPTIONS exists, add it to the ghc command line? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
Brandon S. Allbery KF8NH wrote:
On 2008 Jul 24, at 3:42, Spencer Janssen wrote:
On Wed, Jul 23, 2008 at 10:54:52PM -0600, Justin Bogner wrote:
The case sensitive default filesystem on OS X angers me once again. Personally, I've reformatted to the case sensitive version of HFS, but I can see how this would be a concern.
Sadly, not everyone can do so; Adobe products tend to rely on case insensitivity.
{-# OPTIONS_GHC -i. #-}
I think -i is a "static" flag -- flags that must be on the commandline, and can't be set in a pragma.
Can xmonad look for an environment variable containing options? Say, if $XMONAD_GHC_OPTIONS exists, add it to the ghc command line?
Similarly, we could have a command line option to specify extra ghc command line options, but that seems pretty awkward. Another idea would be to store some extra flags to ghc in the config itself, but that's obviously a chicken and egg problem.
Spencer Janssen wrote:
On Wed, Jul 23, 2008 at 04:12:08PM -0600, Justin Bogner wrote:
recompile calls ghc --make, but supplies the -i argument, which suppresses including the current directory in the search path. This means that one can't break up xmonad.hs into modules in their own .xmonad directory.
I don't see any particularly good reason to prevent this, so here's a patch that removes the -i argument. An equivalent change would be to change "-i" to "-i.", which explicitly sets the search path, but the ghc docs state that this is the default anyway, so I think that removing it makes more sense.
This is not compatible with case-insensitive file systems, such as those on OS X. When the user writes 'import XMonad', GHC will attempt to use ~/.xmonad/xmonad.hs rather than the installed library module.
Couldn't we have it search first in the XMonad-libraries, and then in the current directory if a module wasn't found there? Does GHC support this? -Isaac
On Thu, Jul 24, 2008 at 10:24 AM, Isaac Dupree
Couldn't we have it search first in the XMonad-libraries, and then in the current directory if a module wasn't found there? Does GHC support this?
Maybe instead of adding '.' to the search path, we could add '~/.xmonad/lib/', or something similar? I just did some testing, and it looks like GHC doesn't mind if a path directory doesn't exist. -- Fred
participants (5)
-
Brandon S. Allbery KF8NH -
Fred Blasdel -
Isaac Dupree -
Justin Bogner -
Spencer Janssen