This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 08 Jan, 2005 3 commits
    • ijones's avatar
      fix from krasimir for getHomeDirectory · 20c33412
      ijones authored
        I added getHomeDirectory function to Distribution.Compat.Directory
        which
        now is used from GHCPackageConfig.localPackageConfig instead of
        (getEnv "HOME").
        Without this fix the build process under Windows terminate with
        "does not exists (no environment variable)".
        
        NOTE: The fix works only if Cabal is built with ghc-6.3+. In any other case
        getHomeDirectory is defined as getEnv "HOME" and will continue to fail.
        This can be fixed but it will add an additional dependency of Cabal from
        shell32 under Windows and ghc < 6.3. I decided to leave the things at this
        stage because they are more maintainable in this way. If this is a pain I
        can rewrite the things latter.
      20c33412
    • ijones's avatar
      added getopt · af8a732f
      ijones authored
      af8a732f
    • ijones's avatar
      executables that depend on package TODO · 98f9d16d
      ijones authored
      98f9d16d
  2. 07 Jan, 2005 3 commits
    • ijones's avatar
      fixed case where two main modules are in the same directory · 4238a696
      ijones authored
      It's pretty common to have a situation where two modules with
      different filenames are both named Main.  If they're in the same
      directory, and we use the -odir and -hidir flags, ghc --make uses the
      Main.o produced from the first build to link the 2nd!
      
      I added a pretty tricky test case for this, after it was reported by
      Ganes Sittampalam while trying to build the HaXmL executables.
      
      I fixed it today by adding the executable name to the -odir and -hidir
      paths, to make sure that they don't use the same Main.o... this is a
      bit inefficient, though, because I'm pretty sure that means it will
      rebuild any bits of the library it depends on for each executable.
      
      Any objections to this?
      4238a696
    • ijones's avatar
      fixed three bugs in the parser and pretty printer · 00bedcb7
      ijones authored
      Two of the bugs were passing the wrong accessor function to the pretty
      printer.
      
      The third bug was that the pretty printer rendered "foo\\bar" as
      "foo\bar", but actually in order to get the slash into the string, the
      user would have to have used the quote syntax.  I think we decided
      that the quote syntax meant a haskell string, so they should input it
      as "foo\\bar", of course internally represented as "foo\bar', but when
      printed, it should show two slashes again.
      00bedcb7
    • ijones's avatar
      ad1c4ef3
  3. 06 Jan, 2005 14 commits
  4. 03 Jan, 2005 5 commits
  5. 02 Jan, 2005 3 commits
  6. 01 Jan, 2005 7 commits
  7. 31 Dec, 2004 1 commit
  8. 30 Dec, 2004 4 commits
    • ijones's avatar
      cvs commit blob from ross patterson · 9ef44ff2
      ijones authored
      ** haddock fixes
      
      ** Add the following fields to PackageDescription:
        
        	buildPackage   :: Bool,         -- ^ package is buildable here
        	ccOptions      :: [String],     -- ^ options for C compiler
        	ldOptions      :: [String],     -- ^ options for linker
        	frameworks     :: [String],
        
        When these are system dependent (as they often are), they will need to be
        overridden, but the mechanism is left to the Cabal user.
        
        Not that I've treated these as basic fields, so they apply to the library
        (if any) and all executables in the package.  The overriding is easier
        that way.
      
      ** Make the build prefix settable with the --builddir option to configure
        (in Simple), save this in the LocalBuildInfo, and use it in subsequent
        phases.
        
        This is useful for the Hugs build, where we want to place the built
        libraries so that we can easily use them inplace.
      
      ** Some rearrangement, centring on changes to the definition of
        PPSuffixHandler:
        
        * removed the special treatment of literate source: a separate
          preprocessor can be used for these if required.
        
        * handlers can use package and local build info to construct the
          appropriate preprocessor.
        
        Also, the supplied suffix handlers list now only has entries for suffixes
        that need preprocessing (i.e. not .hs or .lhs).  Dummy entries for the
        suffixes handled by the compiler are added internally.
      
      **  Add a function getOptionsFromSource to fetch LANGUAGE and OPTIONS pragmas
        from the initial part of a Haskell source module (as proposed by SimonM
        on the libraries list).
        
        Also export the auxiliary function stripComments, which does what it says,
        optionally preserving pragmas.
      
      9ef44ff2
    • ijones's avatar
      more refactoring of InstallCmd · 9069b9a4
      ijones authored
      9069b9a4
    • ijones's avatar
      65c0fccc
    • ijones's avatar
      factored mprefix out of InstallCmd · 430c1c9c
      ijones authored
      430c1c9c