Subject: darcs patch: Made it possible to run executeables with data files i...
From: Johan Tibell <[email-masked]>
To: [email-masked]
Date: Sun, 13 Apr 2008 15:45:09 +0200 (CEST)

Sun Apr 13 15:41:55 CEST 2008  Johan Tibell <[email-masked]>
  * Made it possible to run executeables with data files in place.
  Added an environment variable, DATA_DIR, that is checked before the
  installation data directory is used.

New patches:

[Made it possible to run executeables with data files in place.
Johan Tibell <[email-masked]>**20080413134155
 Added an environment variable, DATA_DIR, that is checked before the
 installation data directory is used.
] {
adddir ./tests/systemTests/dataDir
hunk ./Distribution/Simple/Build.hs 5
--- 
+--
hunk ./Distribution/Simple/Build.hs 50
-import Distribution.PackageDescription 
+import Distribution.PackageDescription
hunk ./Distribution/Simple/Build.hs 176
-	"import Data.Version"++
+	"import Data.Version\n"++
+        "import System.Environment"++
hunk ./Distribution/Simple/Build.hs 194
-	  "getDataDir = return datadir\n"++
+	  "getDataDir = "++mkGetEnvOr "DATA_DIR" "return datadir"++"\n"++
hunk ./Distribution/Simple/Build.hs 198
-	  "getDataFileName name = return (datadir ++ "++path_sep++" ++ name)\n"
+	  "getDataFileName name = do\n"++
+	  "  dir <- getDataDir\n"++
+          "  return (dir ++ "++path_sep++" ++ name)\n"
hunk ./Distribution/Simple/Build.hs 210
-	  "getDataDir =  "++mkGetDir flat_datadir flat_datadirrel++"\n\n"++
+	  "getDataDir =  "++ mkGetEnvOr "DATA_DIR"
+                              (mkGetDir flat_datadir flat_datadirrel)++"\n\n"++
hunk ./Distribution/Simple/Build.hs 245
-	
+
hunk ./Distribution/Simple/Build.hs 249
+        mkGetEnvOr var expr = "catch (getEnv \""++var++"\")"++
+                              " (const $ "++expr++")"
+
addfile ./tests/systemTests/dataDir/Exe.hs
hunk ./tests/systemTests/dataDir/Exe.hs 1
+module Main where
+
+import Control.Monad (unless)
+import Paths_test (getDataFileName)
+import System.Directory (doesFileExist)
+import System.Exit (exitFailure)
+import System.IO (putStrLn)
+
+main :: IO ()
+main = do
+  fname <- getDataFileName "data-file"
+  exists <- doesFileExist fname
+  if exists
+     then return ()
+     else do putStrLn "Failure."
+             print fname
+             exitFailure
addfile ./tests/systemTests/dataDir/data-file
addfile ./tests/systemTests/dataDir/dataDir.cabal
hunk ./tests/systemTests/dataDir/dataDir.cabal 1
+name: test
+version: 0.1
+build-type: Simple
+cabal-version: >= 1.2
+data-files: data-file
+
+-- This test passes if running the below executeable doesn't return an
+-- 'exitFailure' status code.
+
+executable exe
+  main-is: Exe.hs
+--  other-modules: Paths_test
+  build-depends: base, directory
}

Context:

[fix for #187 -- directory of Paths_packagename is included when looking for source files
Andres Loeh <[email-masked]>**20080412204904] 
[Check for the required cabal version early in parsing
Duncan Coutts <[email-masked]>**20080409154655
 Previously we only checked the "cabal-version" field after parsing
 and all other configure processing. If the package really needs a
 later Cabal version it is of course highly likely that parsing or
 configure are going to fail and the user is not going to get the
 helpful error message about the version of Cabal required. So now
 we do the check early during parsing. If a later version is
 required and parsing subsequently fails, we now report the version
 issue, not the subsequent parse error. If parsing succeeds we
 still issue a warning which should be a useful hint to the user if
 subsequent configure processing fails.
] 
[Use relative file paths in .cabal parse error messages
Duncan Coutts <[email-masked]>**20080409154030
 Do this by normalising the file path in the error message
 and when looking for .cabal files, by looking in '.' rather
 than the absolute path of the current directory.
] 
[Remove unused import
Duncan Coutts <[email-masked]>**20080409073352] 
[Fix for detecting ~/.cabal/ dir as a .cabal file
Duncan Coutts <[email-masked]>**20080409073236
 Which happened if you use cabal configure in your home dir.
 Now produced the right error message, or if you actually put
 a cabal project in your home dir, it might actually work.
 Also, do the same fix for findHookedPackageDesc.
] 
[Fix spelling in error message
Duncan Coutts <[email-masked]>**20080408134610] 
[Fix names of profiling libs
Duncan Coutts <[email-masked]>**20080407013449
 I broke this recently when refactoring. Restore the original behaviour.
 Was generating "libHSfoo_p-1.0.a" when it should be "libHSfoo-1.0_p.a".
] 
[TAG 1.5.1
Duncan Coutts <[email-masked]>**20080329181329] 
Patch bundle hash:
2d46273207abf02cc90dcfcfe1d717afd11ade78